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Dear DECUS Member, 

By the time you read this, Spring DECUS will be far in the past, but I am still recovering 
from a seven-day stretch of meetings from 7:30am till 11:00 or so every night. I would like 
to have more time to prepare this message, but another deadline is approaching, and I'm 
going to take the holiday weekend off and spend some time away from a keyboard and 
DECUS and my real-time job, so this letter is going out now! 

First off, yes readers, we did have some problems with print quality in the May issue. The 
RSTS section really came out poorly, but we're not sure exactly why. Other two up 
sections, (HMS, L&T, RT,) look reasonable. We are dealing with a new printer (located in 
the Midwest so that we save a lot on bulk mailing costs,) and we're still getting used to 
each other. Hopefully we will have things sorted out the time you read this. 

Everyone seemed to agree that Cincinnati was one of the best. Several things important 
occurred at the symposium that involved the Newsletters, and I want to make you aware 
of what happened. 

For the first time, the Newsletters had a booth at DECUS. It was right next to the Store, so 
we were easy to find. The booth let us show first time DECUS members just what the SIG's 
Newsletters were all about. Members could sign up there, (or renew their subscription,) or 
take home a form and send it in later. We also answered a lot of questions from readers 
who weren't sure when their subscription would lapse (or when it had.) 

We also handed out a small survey to attendees which we hope will give the Editors a 
better idea of what the readers wanted in the newsletters. To all of you who took time to 
stop by the booth and fill a survey out, "Thank you." 

All in all, though it wasn't SRO quality, the booth was definitely a hit, and we plan on 
continuing it. The only thing we could have used were a few more volunteers to spend 
time in the booth. If you came by the booth and didn't find anyone to talk to we're sorry 
about that, and hope to have things better supported by next Symposium. 

The other thing that came out of Spring DECUS was a consensus of opinion from LRP, 
(Communications Committee Long Range Planning,) CommComm Exec, and the NLC, 
(National Lug Council,) that there needs to be more communication between the SIGs 
Newsletters and the local LUG Newsletters. For the first time I was aware of, several SIGs 
Newsletter Editors attended a LUG Newsletter Editor session Friday Morning, and ex¬ 
changed thoughts on how to nurture this communication between SIGs and LUGs. 

Since it seems like such a great idea, how do we start this interchange? I humbly suggest 
the following. 

For LUG Newsletter editors, if you have something you think would be of interest to 
readers outside your LUG, send a copy to the appropriate SIG Newsletter editor, or to 
me. If it's a length article, most editors have systems with Kermit or some other protocol 
available for transfer. We're not fussy, we'll use DCS, BITNET, INTERNET, FIDONET, 
anything but hairnet to transfer files. There's also the U S mail and floppies or tapes too. 
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Better yet, if you can swing an added name or two on your mailing list, add me or your 
favorite Newsletter editors to your mailing lists. We may see something that fits beauti¬ 
fully into an upcoming issue. 

Some of our editors publish LUG news sections, listing upcoming meetings and topics. I 
wish more editors would. The only problem is that editors would have to have the infor¬ 
mation by the 15th of any month to get it into the Newsletter that conies out 6 weeks later. 
Any LUG editors are welcome to send meeting information to the appropriate editor. 

Don't forget the other direction. If you see something in the SIGs Newsletters that you 
would like to use, (maybe you're having a meeting with a central topic, and some reprints 
from the Newsletters would make a great handout,) get in touch with the editor. Most of 
us will be glad to send you sources any way we can. 

In conclusion, I think if this idea is to work its the LUG editors who must start the ball 
rolling. We SIG editors are outnumbered about 150 to 22, and we don't know who the 
local Editors or LUG chairs are. There are a lot of people on DCS who are also LUG chairs 
or editors. How bout it folks? Could a few of you take some time and get things started. 

If anyone wants to talk to me, or put me on a mailing list, please write or call. 

Frank R. Borger 
Michael Reese Medical Center 
Dept, of Radiation Physics 
Lake Shore Drive at 31st St 
Chicago, IL 60616 
1-312-791-8075 
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SOME LIGHT ON DAARC 


Jim Deck DAARC Sig Chairman 

There seems to be a mystery to some people as to what the DAARC SIG is all about. At its inception, it 
was felt that the name DAARC (Data Acquisition Analysis Research and Control) was fairly descriptive. 
Let it be known to all of DECUS that DAARC embraces all who practice their computer crafts in REAL 
TIME or are concerned with the analysis of data. Without a philosophical discussion of just what REAL 
TIME is, (perhaps an excellent DECUSERVE topic) let me say that those who must acquire data from 
industrial processes or laboratory experiments as well as those who must try to make some sense from the 
data they’ve collected will find the DAARC SIG a gathering place for their peers. 

Now that you know, come join us and expand your horizons while sharing with others who face similar 
problems. Problems peculiar to those who would gather in the DAARC. 


THANKS FOR THE HELP 

Dale Hutchison DAARC SIG Newsletter Editor 

Having just returned from the DECUS Symposium in Cincinnati, I have been asked to extend the thanks 
for the DAARC SIG for the help received from the following members and friends. 


Roger Frazita 
Cummins Engine Co. 

Jim Duba 

Cummins Engine Co. 

Dale Hutchison 
Cummins Engine Co 


Stan Schultes 
Corning Glass Works 

Mike Gallant 
Cummins Engine Co. 

Tom Vaughan 
CODA Systems 


George Winkler 
CPC International 


Jim Deck 

Inland Steel Research Labs 


Bill Tippie 
Kinetic Systems 

Jeff Kita 
CODA Systems 

Jane Furze 
?? 


We would also like to extend our thanks to the many folks from Digital Equipment Corporation that gave 
sessions, manned the booths, attended working group sessions, and helped out in general. As always there 
is a chance that I have missed someone, If I have, please accept my apologies. 

For those of you that weren’t fortunate enough to be able to attend the Symposia, you missed a lot. 
Following is a brief article from Jim Duba with a first timers point of view. 

In other news, Proceeding from this symposia can be ordered. Contact the DECUS office for prices, etc. 
(617-480-3418). 

First Time at Symposia 

Jim Duba, Cummins Engine Co. 

After working with DEC hardware and software for about five years, I finally got to go to a symposium. I 
want tell about what it feels like to be among a large group of DEC users in a very friendly environment. 
What it feels like to go to session after session until they blur and merge and you can only separate them 
by referring to your notes. Finally, I want to encourage all DECUS members to go to one of these things. 

I understand that about 5700 people showed up for the symposium in Cincinnati. Everything was very well 
organized and the attendees went along with the organization in a cooperative, friendly way. The organizers 
should be congratulated and their privileges increased. 

These 5700 people moved purposefully from place to place. Conversations were often quiet and intense. 
People really stick to business. Even at parties people were talking computers, exchanging business cards, 
and taking notes. 
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A lot of the people moving around were searching thru the available sessions. What happens is you sit in 
a session and it doesn’t fit, branch to another that might. Sitting and branching go on until something 
satisfactory is fount. Matching skills and interest to sessions is somewhat difficult because of the large 
number of sessions and the sometimes funny way they are scheduled against each other and the abstract 
doesn’t provide a lot of information about how detailed the session will be. 

I talked with people from corporation presidents to lowly programmers. With those still coming to grips 
with basic DCL to wizards running in kernel mode. I sat in sessions ranging from glossy product overviews 
to details about how interrupts work. I left sessions out of boredom and because I couldn’t keep up. 

I learned a lot and I was able to answer a couple of questions. That’s what DECUS is all about. It has 
reached a critical mass so that everything going on in DEC LAND is represented. The more people that 
get there, the better the representation will be. I really want to encourage everyone to go to the next 
symposium, because someone out there will have answers to my next set of questions. 

VAX/VMS REALTIME PERFORMANCE CHARACTERIZATION 

Eric Gauthier and Bill Forbes, Laboratory Data Products, Systems Engineering 

The distinguishing feature of realtime applications is the necessity of responding to asynchronous events 
within a critical time-window. Furthermore, the time constraints are usually absolute; if the system fails to 
respond within the required time-window for even a single event, the application as a whole fails. For this 
reason, designers of realtime computer systems have an extraordinary need for accurate, reliable, and 
detailed information about the performance characteristics of their systems. The purpose of this paper is to 
show how the LDP Systems Engineering group gathers and interprets realtime performance information 
and to get feedback on the appropriateness of our methods and results to user applications. 

The information presented in this paper is meant to serve as a basis for discussions of VAX/VMS realtime 
performance. It does not constitute a committment from DEC as to what realtime performance is achiev¬ 
able on your system operating under your particular application load (see below). 

WHAT ARE REALTIME PERFORMANCE DATA USED FOR? 

The need for performance information is felt throughout all phases of a realtime application development 
project. In the early stages, the application designer must select a platform system and make preliminary 
configuration decisions. Systems which fail to meet minimal performance criteria are excluded from further 
consideration, while those which can meet the performance demands of the application are subsequently 
evaluated according to less rigid criteria, such as system cost, ease of development, maintainability, and so 
forth. In the mid-stages of the project, realtime performance testing is used to determine whether the 
implementation of the design is achieving the expected performance. Moreover, in this phase, the design is 
often "fine-tuned", either in response to changes in the target application or through a desire to build in 
the maximum marginal performance capacity so that future extensions of the application can be imple¬ 
mented easily. In the final stages of the project, performance testing is important in integration testing 
and final system qualification. 

Given this diversity in the possible goals of performance characterization, it is difficult to define a set of 
metrics which meet every need. The problem is compounded by the fact that any given set of performance 
metrics can (and should!) be interpretted differently, depending on the intent of the evaluation. In general, 
there are two kinds of questions that performance data address: 

• What are the performance characteristics of the system? 

• What is going on "inside" the system that affects its performance? 

When seeking to answer the first type of question, users generally want to know whether the worst-case 
performance, with respect to some particular metric, exceeds some threshold requirement for their applica¬ 
tion. In this case, they are looking for a single number that is a valid metric of worst-case performance. 

When seeking to answer the second type of question, users need information in a form which exposes the 
factors which contribute to variation in the metric. In this case, the ultimate goal of performance 
evaluation is to optimize the design so as to get the best or most consistent performance. 
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TIMING HISTOGRAMS - WHAT DO THEY SHOW? 

Realtime performance testing differs from non-realtime testing in that every individual data value across 
many thousands or millions of iterations of the test is of potential interest. Average performance is 
generally of little interest to realtime users. For this reason, the results of realtime performance test are 
often cast into a histogram in which the incidence of each value across many iterations is represented. 
From such histograms, it is possible to extract not only the mean and maximum timing, but the position 
and relative magnitude of various peaks in the distribution, as well. Such peaks and other characteristics of 
the shape of the histogram can reveal a great deal about the underlying factors which affect performance. 
There are two main classes of factors which contribute to the variability of realtime performance results: 
pre-empting events and blocking events. 

Pre-empting events are those which cause the processor to suspend execution of the code path which is 
being measured and execute a higher-priority code path to service the event. When the high-priority code 
path completes, control returns to the pre-empted path and it is allowed to complete. If the measured code 
path is frequently pre-empted by some particular event, a peak will appear in the performance histogram, 
indicating that a code path of some fixed length was interpolated within the measured code path on some 
of the test iterations. 

Blocking events are those which can prevent the measured code path from executing, if the blocking code 
path happens to be in the process of executing when the code path to be measured becomes computable. 
However, if a blocking code path becomes computable AFTER the measured code path begins to execute, 
the measured code path will complete before the blocking code path executes; that is, no pre-emption will 
occur. Blocking events cause the appearance of plateaus in the region of the mode of a performance 
histogram. 

The interpretation of complex performance histograms can be difficult due to the cross-interaction of 
multiple blocking and pre-empting events. However, simple histograms can be used to analyse the nature 
and interactions among small numbers of blocking and pre-empting events. 

"YOUR MILEAGE MAY VARY..." 

For most realtime performance metrics, the modal (most common) timing is relatively invariant, since the 
most common outcome of a well designed test is that the measured code path executes without being 
blocked or pre-empted. However, the maximum timing observed over many iterations of a test is highly 
dependent upon the occurance of pre-empting and blocking events. In short, the maximum value of a 
metric is usually more indicative of system load than it is of the basic performance of the code path being 
measured. 

For this reason, it is impossible to state what the guaranteed performance of a system will be unless the 
measurements are performed under identical load conditions. In this context ''load" includes not only what 
processes are running concurrently with the test, but what the software and hardware configuration of the 
system is, since these things affect the distribution and availability of system resources. The data which we 
have included below are presented in the context of the particular hardware and software configuration 
shown and should not be generalized outside that context. 

1 BASIC METHODOLOGY 

1.1 Test Conditions 

When characterizing a system’s performance it is very important to understand the exact 
configuration of the system under test (SUT). That understanding includes the complete hardware and 
software configuration, and the system loads. When reporting performance results it is very important 
the results remain within the context of the SUT’s configuration. This bundling of data and system 
definition should allow for repeatability in testing, and discourage the misuse of performance numbers. 
We ask that the numbers reported here be kept intact with the system definitions so as not to lose 
their context. 

Hardware Configuration 
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The hardware configuration of a test system is a fundamental part of a test scenario. The location of 
devices on the bus is very important in the case of simultaneous interrupts. When devices of equal 
priority level request an interrupt, priority is given to the device which is electrically closest to the 
processor. 

The results presented in this report were generated on two different Q-bus based systems. Each 
hardware configuration is listed below. 

1. MicroVAX II 

Configuration: A 
Serial Number: WF610K6540 
Microcode Rev: 00 
Hardware Rev: 00 

Slot Device Rev Description 

1 KA630 H2 CPU Board with VT100 as console 

2 MS630-BA 02 4MB Memory 
3(AB) KWV11-C Ml Realtime Clock 

4(AB) DZV11 Cl Asynchronous Serial Interface 

5(AB) DEQNA-M F2 Ethernet QBUS Network Adaptor 

5(CD) TQK50 FI TK50 Controller 

6(CD) RQDX3 Cl Disk Controller 

RD53-A A1 71 MB Disk Drive 

RD52-A B1 

2. VAX 3600 

Configuration: B 
Serial Number: WF728D6358 
Microcode: 1 
Hardware: V2.0 

Slot Device Rev Description 

1 KA650 proto CPU with VT241 as console 

2 MS650-AA A1 8 MB ECC Memory 

3 KWV11-SA A1 Realtime Clock 

4 TQK70-SA X22 TMSCP Controller 
TK70-AA X06 295 MB Tape Drive 

5 KDA50-QA E02 SDI Controller 

6 KDA50-QA E02 Second Module of SDI 
RA82-JA C2 622 MB Disk Drive 

Software Configuration 

Another fundamental part of a test scenario, and the most frequently overlooked, is the software 
configuration. Important characteristics of the software configuration are the operating system and 
version, SYSGEN parameters, and installed images. 

The operating system is an obvious factor in performance measurements. Different operating systems 
may have very different code paths, device drivers, etc., and the results from testing may only be used 
to show the advantages/disadvantages between the two. All tests shown here were run under VAX/ 
VMS X4.6. 

For the current tests, all processes ran at an elevated software priority and their working set limits in 
the User Authorization File (UAF) were changed to the values shown below. 

Working Set /Limit= 1024 /Quotas 2048 /Extent= 2048 
Adjustment enabled Authorized Quota= 2048 Authorized Extent” 2048 

Installed images are a factor of performance because installation can cause memory to be allocated 
from non-paged pooled memory. This can reduce the amount of memory available to realtime 
processes. 
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The SYSGEN parameters of a system determine the configuration of the operating system. It is 
important to show these parameters for each SUT because they determine such things as process 
quantam, global pages available, the size of the free page list, and many other factors that are critical 
to realtime computing. 

One SYSGEN parameter that was changed for our tests is REALTTME^SPTS. This defines the 
number of system page table entries that may be used by realtime processes. The entries are used to 
map process-specified buffers into system space. The number of entries must be greater than or equal 
to the number of pages in buffers that have been specified by processes connected to interrupt vectors. 

The SYSGEN parameters are available by contacting the DAARC Newsletter Editor. 

Dale Hutchison 
Cummins Engine Company 
4720 Baker Street Ext. 

Lakewood, NY 14750 
(716) 456-2191 


Installed images for Test System A (MicroVAX II) 

DISK$VAXVMSRL4:{EMACS}.EXE 

EMACS;1 Open Shar 

EMACSSHR;! Open Shar Lnkbl 


DISKS VAXVM SRL4:{ S Y SO. S YSEXE}. EXE 


2020V2A10;1 

Open 

Hdr 

Shar 



ANALIMDMP;1 




Prv 


AUTHORIZE; 1 




Prv 


CDU;1 

Open 

Hdr 


Prv 


COPY;l 

Open 

Hdr 

Shar 



DCL;1 

Open 

Hdr 

Shar 


Lnkbl 

DELETE; 1 

Open 

Hdr 

Shar 



DIRECTORY; 1 

Open 

Hdr 

Shar 



EDT;1 

Open 

Hdr 

Shar 



EVL;1 




Prv 


FAL;1 

Open 

Hdr 

Shar 



FTSV;1 

Open 


Shar 

Prv 


FTSVEXEC; 1 

Open 


Shar 

Prv 


INIT;1 




Prv 


INSTALL; 1 




Prv 


LINK;1 

Open 

Hdr 




LOGINOUT; 1 

Open 

Hdr 

Shar 

Prv 


MAIL;1 




Prv 


MONITOR; 1 

Open 

Hdr 


Prv 


NETSERVER;1 

Open 

Hdr 

Shar 



NICONFIGjl 




Prv 


PHONE; 1 




Prv 


RENAME; 1 

Open 

Hdr 

Shar 



REQUEST; 1 




Prv 


RTPADjl 




Prv 


SEARCH; 1 

Open 

Hdr 

Shar 



SET;1 

Open 

Hdr 

Shar 

Prv 


SETP0;1 

Open 

Hdr 

Shar 

Prv 


SETRIGHTS;1 




Prv 


SHOW;l 

Open 

Hdr 

Shar 

Prv 


SHWCLSTR;1 




Prv 


SUBMIT; 1 

Open 

Hdr 

Shar 

Prv 


TPU;1 

Open 

Hdr 

Shar 
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TYPE;1 

Open 

Hdr 

Shar 


VMSHELP;1 

Open 

Hdr 

Shar 


VPM;1 

Open 

Hdr 


Prv 


DI SK$ VAXVM SRL4:{ S YSO. SYSLIB}.EXE 


ADARTL;1 

Open 

Hdr 

Shar 


Lnkbl 


BASRTLjl 

Open 

Hdr 



Lnkbl 


BASRTL2;1 







COBRTLjl 

Open 

Hdr 



Lnkbl 


CONVSHR;l 







CRFSHR;1 

Open 

Hdr 

Shar 


Lnkbl 


DBGSSISHR;1 

Open 

Hdr 

Shar 

Prot 

Lnkbl 


DCLTABLES;10 

Open 

Hdr 

Shar 


Lnkbl 


DCXSHR;1 

Open 

Hdr 

Shar 


Lnkbl 


DEBUG; 1 

Open 

Hdr 

Shar 


Lnkbl 


DISMNTSHR;1 

Open 

Hdr 

Shar 

Prot 

Lnkbl 

Nopurg 

EDTSHR;1 

Open 

Hdr 

Shar 


Lnkbl 


FDLSHR;1 







FORRTL; 1 

Open 

Hdr 



Lnkbl 


LBRSHR;1 

Open 

Hdr 

Shar 


Lnkbl 


LIBRTL;1 

Open 

Hdr 

Shar 


Lnkbl 


LIBRTL2;1 







MOUNTSHRjl 

Open 

Hdr 

Shar 

Prot 

Lnkbl 


NMLSHR;1 

Open 

Hdr 

Shar 


Lnkbl 


PASRTLjl 

Open 

Hdr 



Lnkbl 


PLIRTL;1 

Open 

Hdr 



Lnkbl 


RPGRTL; 1 







SCNRTL; 1 

Open 

Hdr 

Shar 


Lnkbl 


SCRSHR; 1 

Open 

Hdr 

Shar 


Lnkbl 


SECURESHRjl 

Open 

Hdr 

Shar 

Prot 

Lnkbl 


SMGSHR;1 

Open 

Hdr 

Shar 


Lnkbl 


SORTSHR;l 







SPISHR;1 

Open 

Hdr 

Shar 

Prot 

Lnkbl 


SUMSHRjl 

Open 

Hdr 

Shar 


Lnkbl 


TPU$CCTSHR;1 

Open 

Hdr 

Shar 


Lnkbl 


TPUSHR;1 

Open 

Hdr 

Shar 


Lnkbl 


TRACE; 1 

Open 

Hdr 

Shar 


Lnkbl 


UVMTHRTLjl 

Open 

Hdr 

Shar 


Lnkbl 


VAXCRTL;2 

Open 

Hdr 

Shar 


Lnkbl 


VAXCRTLG;2 

Open 

Hdr 

Shar 


Lnkbl 


VMSRTL;! 

Open 

Hdr 

Shar 


Lnkbl 



DISK$VAXVMSRL4:{ SYSO.SYSMSGJ.EXE 


CLIUTLMSGjl 

DBGTBKMSG;1 

FILMNTMSG;1 

NETWRKMSG;1 

PASMSG;1 

PLIMSG; 1 

Open 

Hdr 

Shar 

Lnkbl 

PRGDEVMSG;1 

RPGMSG;1 

Open 

Hdr 

Shar 

Lnkbl 

SHRIMGMSG;1 

SYSMGTMSG;1 

Open 

Hdr 

Shar 

Lnkbl 

TPUMSG;! 

Open 

Hdr 

Shar 

Lnkbl 
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Installed images for Test System B (VAX 3600) 


DISK$VAXVMSRL4:{SYS0. SYSEXEj.EXE 


ANALIMDMP;1 




Prv 



AUTHORIZE; 1 




Prv 



CDU;1 

Open 

Hdr 


Prv 



COPY; 1 

Open 

Hdr 

Shar 




DCL;1 

Open 

Hdr 

Shar 


Lnkbl 


DELETE; 1 

Open 

Hdr 

Shar 




DIRECTORY; 1 

Open 

Hdr 

Shar 




EDT;1 

Open 

Hdr 

Shar 




EVL;1 




Prv 



FTSV;2 

Open 


Shar 

Prv 



FTSVEXEC;2 

Open 


Shar 

Prv 



INIT;1 




Prv 



INSTALL; 1 




Prv 



LINK;1 

Open 

Hdr 





LOGINOUTjl 

Open 

Hdr 

Shar 

Prv 



MAIL; 1 

Open 

Hdr 

Shar 

Prv 



MONITOR; 1 

Open 

Hdr 


Prv 



NICONFIG; 1 




Prv 



PHONE; 1 

Open 

Hdr 

Shar 

Prv 



RENAME; 1 

Open 

Hdr 

Shar 




REQUEST; 1 




Prv 



RTPAD;1 

Open 

Hdr 

Shar 

Prv 



SEARCH; 1 

Open 

Hdr 

Shar 




SET;1 

Open 

Hdr 

Shar 

Prv 



SETP0;1 

Open 

Hdr 

Shar 

Prv 



SETRIGHTSjl 




Prv 



SHOW;l 

Open 

Hdr 

Shar 

Prv 



SHWCLSTR;1 




Prv 



SUBMIT; 1 

Open 

Hdr 

Shar 

Prv 



TPU;1 

Open 

Hdr 

Shar 




TYPE;1 

Open 

Hdr 

Shar 




VMSHELP;1 

Open 

Hdr 

Shar 




VPM;1 

Open 

Hdr 


Prv 



DISK$VAXVMSRL4:{SYS0. SYSLIBJ.EXE 




ADARTLjl 

Open 

Hdr 

Shar 


Lnkbl 


BASRTL; 1 

Open 

Hdr 



Lnkbl 


BASRTL2; 1 







COBRTL;l 

Open 

Hdr 



Lnkbl 


CONVSHRjl 







CRFSHRjl 

Open 

Hdr 

Shar 


Lnkbl 


DBGSSISHR;1 

Open 

Hdr 

Shar 

Prot 

Lnkbl 


DCLTABLES;5 

Open 

Hdr 

Shar 


Lnkbl 


DCXSHR;1 

Open 

Hdr 

Shar 


Lnkbl 


DEBUG; 1 

Open 

Hdr 

Shar 


Lnkbl 


DISMNTSHR;1 

Open 

Hdr 

Shar 

Prot 

Lnkbl 

Nopurg 

EDTSHR;1 

Open 

Hdr 

Shar 


Lnkbl 


FDLSHR;1 







FORRTL; 1 

Open 

Hdr 



Lnkbl 


LBRSHR;1 

Open 

Hdr 

Shar 


Lnkbl 


LIBRTL;1 

Open 

Hdr 

Shar 


Lnkbl 


LIBRTL2;1 







MOUNTSHR; 1 

Open 

Hdr 

Shar 

Prot 

Lnkbl 
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PASRTL;1 

Open 

Hdr 



Lnkbl 

PLIRTL;1 

Open 

Hdr 



Lnkbl 

RPGRTL;1 






SCNRTL;1 

Open 

Hdr 

Shar 


Lnkbl 

SCRSHR; 1 

Open 

Hdr 

Shar 


Lnkbl 

SECURESHRjl 

Open 

Hdr 

Shar 

Prot 

Lnkbl 

SMGSHR;1 

Open 

Hdr 

Shar 


Lnkbl 

S0RTSHR;1 






SPISHRjl 

Open 

Hdr 

Shar 

Prot 

Lnkbl 

SPMSHRjl 

Open 


Shar 

Prot 

Lnkbl 

SUMSHRjl 

Open 

Hdr 

Shar 


Lnkbl 

TPU$CCTSHR; 1 

Open 

Hdr 

Shar 


Lnkbl 

TPUSHR;1 

Open 

Hdr 

Shar 


Lnkbl 

TRACE; 1 

Open 

Hdr 

Shar 


Lnkbl 

UVMTHRTL; 1 

Open 

Hdr 

Shar 


Lnkbl 

VAXCRTL;2 

Open 

Hdr 

Shar 


Lnkbl 

VAXCRTLG;2 

Open 

Hdr 

Shar 


Lnkbl 

VMSRTL;! 

Open 

Hdr 

Shar 


Lnkbl 


DISK$VAXVMSRL4:{SYS0.SYSMSG}.EXE 


CLIUTLMSGjl 

DBGTBKMSG;1 

FILMNTMSG;1 

NETWRKMSGjl 

PASMSGjl 

PLIMSG; 1 

Open 

Hdr 

Shar 

Lnkbl 

PRGDEVMSG;1 

RPGMSGjl 

Open 

Hdr 

Shar 

Lnkbl 

SHRIMGMSGjl 

SYSMGTMSG;1 

Open 

Hdr 

Shar 

Lnkbl 

TPUMSG;! 

Open 

Hdr 

Shar 

Lnkbl 
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System Load 

In all of the tests the interval timer was running, causing an interrupt at IPL 22 every 10 milliseconds. 
This interrupt could have blocked our ISR tests but could not have pre-empted them. This is due to the 
fact that the KWV interrupts at IPL 20 but the ISR is executed at IPL 23. The system services or 
context switch tests could have been either pre-empted or blocked because timings are recorded in 
process context at IPL 0. Network activity was disabled by stopping both NCP and LATCP. All disk 
I/O was done after the time critical code was completed. All test processes locked their P0 pages into 
memory to prevent paging. In the case of the system service tests, paging could occur on some 
iterations because the system services themselves were not locked into memory. 

The only system processes running during the testing were SWAPPER and NULL. There was no 
OPCOM nor ERRFMT present. 

1.2 Timing Methodologies 

One important issue in realtime performance testing is how events are timed. Our tests use the 
KWV11-C Realtime Clock Module. 

The KWV11-C provides many modes of operations. The interrupt latency tests use the KWV to 
generate an interrupt and time the latency to ISR, AST, and process code. First, the BPR of the KWV 
is loaded with a random negative number. The KWV then counts up; when it reaches zero it generates 
an interrupt and continues counting. When the ISR for the KWV interrupt is entered, it immediatly 
disables the internal oscillator of the KWV and records the time. Upon exit of the ISR the oscillator is 
enabled, allowing for the next routine to repeat the process and record its latency. 

The overhead incurred when stopping the KWV upon entry of the different routines is included in all 
of our timings. This has been done to show the latency until some ’useful’ operation can be performed. 
The time to arrival at the beginning of the ISR is not very helpful to a user because nothing has 
actually happened yet. On the other hand, the time it takes to arrive and perform one instruction at 
the ISR level is of interest, as it represents the time within which an elementary task could be 
accomplished. 

The system service timings and context switch timings use the KWV merely as a counter. The process 
first maps a portion its virtual memory to physical I/O space and directly addresses the control 
registers of the KWV to start and stop the counter. 

The overhead incurred by this method of timing is shown in our tests by the ’NULL’ timing. The first 
time recorded is the time to start, stop, and read the clock. This should give you a good idea of the 
overhead included within the other timings. 

Synchronization is yet another problem of performance characterization. The test could become 
synchronized with many events on the system; the interval timer or another process are two of these. 

We avoid synchronization by loading the KWV with a random number before generating an interrupt. 
This assures us that an interrupt will be generated at an undetermined time, thus reducing the risk of 
synchronization. 

1.3 Statistical Considerations 

An important concern we have in our testing is the number of iterations we perform. All results shown 
here represent tests of one million iterations. The histogram itself should determine the number of 
iterations. The ideal test scenario performs enough iterations so that the histogram will display no 
obscure events, which occur a very small percentage of the time. If an event takes place that causes an 
exceptionally long latency, then the number of iterations of the test should be increased to attempt to 
produce more of those events and to smooth out the histogram. 

Interrupt Latency Test Sequence 
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• Map I/O page into process space for direct I/O 

• Initialize data structures 

• Top of test loop: Assign channel for KWV 

• Preset counter (5000 +/- 2000), start, and enable interrupts 

• Wait for appropriate flag to be set 

• Record ISR, AST, and process latencies 

• Cancel I/O - SYS$CANCEL 

• If loop count > = the number of iterations for this test, then exit; else return to top of the loop 
INTERRUPT RESPONSE DATA 

• Test system A 

• base IPL = 0 

• SW priority =18 

• Wait for VMS LEF set in AST (process is in LEF wait state) 

• CONINTERR driver 

1,000,000 data points. Test time = 02:24:09.24 


VAX/VMS X4.6 on node ll-NOV-1987 11:24:02.44 Uptime 0 03:48:14 


Pid 

Process Name 

State 

Pri 

I/O 

CPU 



Page fits 

Ph.Mem 

00000020 

NULL 


COM 

0 

0 

0 03:39:50.06 


0 

0 

00000021 

SWAPPER 

HIB 

16 

0 

0 00:00:00.88 


0 

0 

00000031 

GAUTHIER 

CUR 

18 

883 

0 00:00:14.97 


2374 

312 

Latencies (microseconds) 










MIN 

MEAN 

MAX 

MODE 

95.0% 

99.0% 

99.5% 


99.9% 


H— 

ISR I 

1 

36 | 

I 

39 | 

115 | 

i 

39 | 

1 

40 | 

1 

40 | 

1 

43 

1 

1 

80 | 


1 

AST j 

1 

1 

604 | 

619 | 

1 

1990 j 

i 

614 | 

1 

1 

654 | 

1 

676 | 

i 

744 

1 

1 

1 

1 

1018 | 
i 


i 

Process | 

780 | 

805 | 

1 

2170 j 

790 | 

830 | 

1 

910 j 

920 

1 

1 

1 

1360 | 



+-—-h 


VAX/VMS X4.6 on node ll-NOV-1987 

13:48:11.68 Uptime 0 06:12:23 



Pid 

Process Name State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 

00000020 

NULL COM 

0 

0 

0 04:59:44.36 

0 

0 

00000021 

SWAPPER HIB 

16 

0 

0 00:00:00.88 

0 

0 

00000031 

GAUTHIER CUR 

18 

1000946 

0 00:50:33.18 

2937 

314 


INTERRUPT RESPONSE DATA 

• Test system B 

• base IPL = 0 

• SW priority =18 

• Wait for VMS LEF set in AST (process is in LEF wait state) 

• CONINTERR driver 

1,000,000 data points. Test time = 01:47:18.49 


VAX/VMS X4.6 on node 10-NOV-1987 15:11:50.89 Uptime 0 00:09:40 


Pid 

Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 

00000080 

NULL 

COM 

0 

0 

0 00:09:10.07 

0 

0 

00000081 

SWAPPER 

HIB 

16 

0 

0 00:00:00.09 

0 

0 

0000008C 

GAUTHIER 

CUR 

18 

660 

0 00:00:04.41 

1914 

326 


DAR-10 














Latencies (microseconds) 




MIN 


MEAN 


MAX 

MODE 

95.0% 


99.0% 


99.5% 


99.9% 


I SR 

1 

1 

18 

1 

1 

21 

1 

1 

43 | 

i 

21 

21 

1 

1 

21 

1 

1 

21 

1 

1 

31 

1 

I 

AST 

1 

1 

1 

260 

1 

1 

268 

1 

1 

1 

1 

688 | 

268 

270 

1 

1 

| 

286 

1 

1 

1 

290 

1 

1 

1 

318 

1 

1 

1 

PROCESS 

1 

1 

310 

1 

1 

328 

1 

750 | 

320 

320 

1 

340 

1 

1 

360 

1 

370 

1 

1 


+-+ 


VAX/VMS X4.6 on node 10-NOV-1987 

16:59:09.38 Uptime 0 01:56:58 



Pid 

Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 

00000080 

NULL 

COM 

0 

0 

0 01:31:58.43 

0 

0 

00000081 

SWAPPER 

HIB 

16 

0 

0 00:00:00.09 

0 

0 

0000008C 

GAUTHIER 

CUR 

18 

1000700 

0 00:19:28.04 

2349 

327 


INTERRUPT RESPONSE DATA 

• Test system A 

• base IPL = 0 

• SW priority =18 

• Wait for user defined flag set in AST (process is CUR) 

• CONINTERR driver 

1,000,000 data points. Test time = 02:15:02.38 


VAX/VMS X4.6 on node 10-NOV-1987 18:32:08.12 Uptime 0 08:15:07 


Pid 

Process Name 

State 

Pri 

I/O 


CPU 


Page fits 

Ph.Mem 

00000020 

NULL 


COM 

0 

0 


0 05:28:41.16 

0 

0 

00000021 

SWAPPER 

HIB 

16 

0 


0 00:00:02.20 

0 

0 

0000004D 

GAUTHIER 

CUR 

18 

1015765 

0 02:11:48.90 

38906 

345 

Latencies (microseconds) 










MIN 

MEAN 

MAX 

MODE 

95.0% 


99.0% 

99.5% 

99.9% 


ISR | 

1 

36 | 

39 | 

1 

128 | 

1 

40 

40 

1 

1 

40 | 

I 

44 | 

" T 

82 | 


AST | 

1 

438 | 

1 

449 | 

1 

1648 j 

446 

470 

1 

1 

1 

500 | 

504 | 

682 | 


Process | 

1 

550 j 

563 | 

1760 | 

560 

580 

1 

1 

600 | 

610 | 

900 | 



+-+ 


+-+ 

VAX/VMS X4.6 on node 10-NOV-1987 20:47:10.50 Uptime 0 10:30:09 

Pid Process Name State Pri I/O CPU Page fits Ph.Mem 

00000020 NULL COM 0 0 0 05:28:43.53 0 0 

00000021 SWAPPER HIB 16 0 0 00:00:02.20 0 0 


0000004D GAUTHIER CUR 18 2015827 0 04:16:17.16 39511 291 

INTERRUPT RESPONSE DATA 

• Test system B 

• base IPL = 0 

• SW priority = 18 

• Wait for user defined flag set in AST (process is CUR) 

• CONINTERR driver 

1,000,000 data points. Test time = 01:43:56.60 
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VAX/VMS X4.6 on node 10-NOV-1987 16:59:47.80 Uptime 0 01:57:37 


Pid 

Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

00000080 

NULL 

COM 

0 

0 

0 01:32:29.23 

0 

00000081 

SWAPPER 

HIB 

16 

0 

0 00:00:00.10 

0 

0000008C 

GAUTHIER 

CUR 

18 

1001343 

0 00:19:33.65 

4117 


Latencies (microseconds) 




MIN 

MEAN 

MAX 

MODE 

95.0% 

99.0% 

99.5% 

99.9% 

I SR 

1 

1 

15 

18 | 

1 

42 

19 

19 

19 

19 

31 

AST 

1 

1 

174 

183 | 

1 

612 

180 

184 

200 

200 

226 

Process 

1 

1 

210 

220 | 

650 

220 

210 

230 

230 

260 


+-+ 


VAX/VMS X4.6 on node 10-NOV-1987 18:43:44.40 Uptime 0 03:41:33 


Pid 

Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

00000080 

NULL 

COM 

0 

0 

0 01:32:30.07 

0 

00000081 

SWAPPER 

HIB 

16 

0 

0 00:00:00.10 

0 

0000008C 

GAUTHIER 

CUR 

18 

2001379 

0 02:00:00.85 

4679 


INTERRUPT RESPONSE DATA 


• Test system A 

• base IPL = 0 

• SW priority =18 

• Wait for VMS EFN set at FORK level (process is in LEF wait state) 

• CONINTERR driver 

1,000,000 data points. Test time = 02:04:16.79 


VAX/VMS X4.6 on node ll-NOV-1987 13:49:10.11 Uptime 0 06:13:22 


Pid 

Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

00000020 

NULL 

COM 

0 

0 

0 05:00:23.18 

0 

00000021 

SWAPPER 

HIB 

16 

0 

0 00:00:00.91 

0 

00000031 

GAUTHIER 

CUR 

18 

1001598 

0 00:50:47.51 

5008 


Latencies (microseconds) 



MIN 

MEAN 

MAX 

MODE 

95.0% 

99.0% 

99.5% 

99.9% 

+ - 

ISR | 

1 

36 | 

1 39 | 

| 105 

1 39 | 

40 | 

i i 

40 | 

1 

43 | 

1 

-+ 

80 | 

1 

1 

Process | 

420 | 

430 | 

1790 

1 420 | 

1 1 
420 | 

1 

460 | 

1 

470 | 

1 

650 j 

+- 

- 



- 

- 



-4. 


VAX/VMS X4.6 on node ll-NOV-1987 15:53:26.90 Uptime 0 08:17:39 


Pid 

Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

00000020 

NULL 

COM 

0 

0 

0 06:20:31.46 

0 

00000021 

SWAPPER 

HIB 

16 

0 

0 00:00:00.91 

0 

00000031 

GAUTHIER 

CUR 

18 

2001624 

0 01:22:14.65 

5494 


Ph.Mem 

0 

0 

361 


Ph.Mem 

0 

0 

367 


Ph.Mem 

0 

0 

350 


Ph.Mem 

0 

0 

351 
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INTERRUPT RESPONSE DATA 

• Test system B 

• base IPL = 0 

• SW priority = 18 

• Wait for VMS EFN set at FORK level (process is in LEF wait state) 

• CONINTERR driver 

1,000,000 data points. Test time = 01:40:56.62 


VAX/VMS X4.6 on node ll-NOV-1987 12:30:33.63 Uptime 0 02:47:08 


Pid 

Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 

00000080 

NULL 

COM 

0 

0 

0 02:46:04.73 

0 

0 

00000081 

SWAPPER 

HIB 

16 

0 

0 00:00:00.12 

0 

0 

0000008E 

GAUTHIER 

CUR 

18 

1498 

0 00:00:24.65 

6644 

336 


Latencies (microseconds) 



MIN 

MEAN 

MAX 

MODE 

95.02 

99.0% 

99.5% 

99.9 % 

+ - 

ISR | 

l 

20 | 

I 

1 22 | 
i I 

63 | 

1 22 | 

1 22 | 

1 22 | 

23 | 

1 36 | 

j 

1 

Process | 

1 

180 j 

1 194 | 

820 | 

| 190 | 

180 

200 | 

200 | 

1 240 | 

+- 








- + 


VAX/VMS X4.6 on node ll-NOV-1987 14:11:30.25 

Uptime 0 04:28:05 



Pid 

Process Name State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 

00000080 

NULL COM 

0 

0 

0 04:08:58.48 

0 

0 

00000081 

SWAPPER HIB 

16 

0 

0 00:00:00.12 

0 

0 

0000008E 

GAUTHIER CUR 

18 

1001513 

0 00:13:49.18 

7014 

348 


INTERRUPT RESPONSE DATA 


• Test system A 

• base IPL = 0 

• SW priority =18 

• Wait for user defined flag set in ISR (process is CUR) 

• CONINTERR driver 

1,000,000 data points. Test time = 01:54:03.72 


VAX/VMS X4.6 on node 10-NOV-1987 20:48:00.52 Uptime 0 10:30:59 


Pid 

Process Name 

State 

Pri 

I/O CPU 

Page fits 

Ph.Mem 

00000020 

NULL 

COM 

0 

0 0 05:29:13.69 

0 

0 

00000021 

SWAPPER 

HIB 

16 

0 0 00:00:02.23 

0 

0 

0000004D 

GAUTHIER 

CUR 

18 

2016461 0 04:16:31.56 

41656 

350 

Latencies (microseconds) 







MIN MEAN 

MAX 

MODE 

95.0% 99.0% 99.5% 

99.9% 


ISR | 

i 

36 | 39 | 

1 1 

108 | 

40 | 
1 

40 | 41 | 43 | 

’ 1 .. I 

82 | 
j 


Process 1 

1 I 

70 1 79 1 

1 

940 1 

1 

70 1 

1 1 

70 1 110 1 110 1 

190 1 



+-+ 
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VAX/VMS X4.6 on node 10-NOV-1987 22:42:04.24 Uptime 0 12:25:03 


Pid 

Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 

00000020 

NULL 

COM 

0 

0 

0 05:29:15.00 

0 

0 

00000021 

SWAPPER 

HIB 

16 

0 

0 00:00:02.23 

0 

0 

0000004D 

GAUTHIER 

CUR 

18 

3016488 

0 06:05:14.74 

42160 

308 


INTERRUPT RESPONSE DATA 


• Test system B 

• base IPL = 0 

• SW priority =18 

• Wait for user defined flag set in ISR (process is CUR) 

• CONINTERR driver 

1,000,000 data points. Test time = 01:36:18.73 


VAX/VMS X4.6 on node 10-NOV-1987 

18:44:14.06 Uptime 

0 03:42:03 



Pid 

Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 

00000080 

NULL 

COM 

0 

0 

0 01:32:52.18 

0 

0 

00000081 

SWAPPER 

HIB 

16 

0 

0 00:00:00.12 

0 

0 

0000008C 

GAUTHIER 

CUR 

18 

2002029 

0 02:00:06.24 

6458 

336 

Latencies (microseconds) 








MIN MEAN 

MAX 

MODE 

95.0% 

99.0% 99.5% 

99.9% 


+- 

ISR 1 

14 1 15 1 

43 1 

16 | 

15 I 

16 1 17 1 

-1- 

28 1 



Process | 20 j 29 j 410 j 20 j 20 j 20 j 30 j 40 j 

+ - + 


VAX/VMS X4.6 on node 10-NOV-1987 

20:20:32.79 

Uptime 

0 05:18:22 



Pid 

Process Name State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 

00000080 

NULL COM 

0 

0 

0 01:32:52.72 

0 

0 

00000081 

SWAPPER HIB 

16 

0 

0 00:00:00.12 

0 

0 

0000008C 

GAUTHIER CUR 

18 

3002045 

0 03:34:17.15 

6954 

347 


* The Process latency numbers are cast into a histogram with a bucket size of 10 microseconds. The 
20 microseconds quoted here actually represents a range from 20-30 microseconds 

Context Switch Test Sequence 


• Lock process’s P0 space into memory to prevent paging 

• Map I/O page into process space for direct IO 

• Create global event flag cluster - SYS$ASCEFC 

• Map global section for communication with proc. "2 

• Initialize data structures 

• Set proc. #1 priority =25 

• Create proc. #2 at priority = 20 

• Wait for proc. #2 to finish initialization 

• Top of loop: Current Process 
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a) Clear and start clock [1] 

b) Stop clock and store (TO) [1] 

c) Clear and Start clock [1] 

d) SYS$SUSPND [1] 

e) Stop clock and store (Tl) [2] 

f) Clear and Start clock [2] 

g) SYS$RESUME on proc. #1 [2] 

h) Stop clock and store (T2) [1] 

i) Clear and Start clock [1] 

j) Wait for a common event flag - SYS$WAITFR [1] 

k) Stop clock and store (T3) [2] 

l) Clear and Start clock [2] 

m) SYS$SETEF [2] 

n) Stop clock and store (T4) [1] 

o) Clear and start clock [2] 

p) SYS$HIBER (1] 

q) Stop clock and store (T5) [2] 

r) Clear and start clock [2] 

s) SYSIWAKE on proc. #1 [2] 

t) Stop clock and store (T6) [1] 


• If loop count > = the number of iterations for this test, then exit; else return to top of the loop 

Timings Tl, T3, and T5 represent the time to switch context from a higher priority process [1] to a 
lower priority process [2] when the higher priority process enters a voluntary wait state. 

Timings T2, T4, and T6 represent the time to switch context when a lower priority process [2] is 
prempted by a higher priority process [1]. 

TO is the time to read the clock. 

CONTEXT SWITCH TIMINGS 

• Test system A 

• base IPL = 0 

• SW priority = 25 (process 1), 20 (process 2) 

1,000,000 data points. Test time = 01:16:25.78 


VAX/VMS X4.6 on node 19-NOV-1987 09:00:28.30 Uptime 0 00:17:58 


Pid 

Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 

00000020 

NULL 

COM 

0 

0 

0 00:16:47.15 

0 

0 

00000021 

SWAPPER 

HIB 

16 

0 

0 00:00:00.15 

0 

0 

0000002B 

CTXSW1 

CUR 

18 

275 

0 00:00:09.19 

1447 

326 




MIN 


MEAN 

MAX 

MODE 

95.0% 

99.0% 

99.5% 

99.9% 

TO 

1 

1 

39 

1 

1 

39 | 

856 | 

39 | 

39 | 

39 | 

I 

39 | 

49 

Tl 

1 

1 

544 

1 

1 

555 | 

1 

1 

1452 j 

i 

1 

550 | 

1 

592 j 

i 

612 | 

1 

1 

638 j 

i 

770 

T2 

1 

1 

1 

728 

1 

1 

1 

1 

741 j 

1 

2100 j 

732 | 

i 

790 j 

1 

866 j 

i 

1 

868 j 

i 

966 

T3 

1 

1 

1 

256 

1 

1 

1 

260 | 

1152 j 

i 

256 j 

i 

260 | 

1 

316 j 

i 

1 

388 | 

i 

396 

T4 

1 

1 

360 

1 

1 

366 | 

I 

1 

1726 j 

1 

1 

362 | 

1 

362 | 

i 

1 

422 j 

i 

1 

426 | 

i 

512 

T5 

1 

1 

1 

240 

1 

1 

1 

245 j 

1 

1116 | 
i 

242 | 

1 

1 

240 j 

i 

1 

370 j 

i 

1 

374 j 

i 

378 

T6 

1 

1 

692 

1 

1 

701 | 

1 

2062 | 

1 

694 | 

752 j 

1 

824 | 

1 

828 | 

920 


+ - + 
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VAX/VMS X4.6 on node 19-NOV-1987 

10:16:54.08 

Uptime 0 01:34:24 




Pid 

Process Name 

State 

Pri 

I/O 

CPU 


Page fits 

Ph.Mem 

00000020 

NULL 

COM 

0 

0 

0 00:16:48.75 

0 

0 

00000021 

SWAPPER 

HIB 

16 

0 

0 00:00:00.18 

0 

0 

0000002B 

CTXSW1 

CUR 

25 

362 

0 00:36:21.14 

2212 

315 

CONTEXT SWITCH TIMINGS 







• Test system B 

• base IPL = 0 








• SW priority = 25 (process 1), 20 

(process 2) 






1,000,000 data points. Test time = 

00:35:18.42 





VAX/VMS X4.6 on node ll-NOV-1987 09:06:21.37 Uptime 0 12:44:00 




Pid 

Process Name 

State 

Pri 

I/O 

CPU 


Page fits 

Ph.Mem 

00000080 

NULL 

COM 

0 

0 

0 12:40:38.87 

0 

0 

00000081 

SWAPPER 

HIB 

16 

0 

0 00:00:00.20 

0 

0 

00000091 

CTXSW1 

CUR 

18 

8913 

0 00:01:13.63 

15967 

427 

Timings in 

microseconds 









MIN MEAN 

MAX 

MODE 95.0% 

99.0% 

99.5% 

99.9% 


TO | 

| 

11 | 13 | 

1 1 

360 | 

1 

13 | 

1 

13 | 

1 

14 | 

14 

1 65 | 


1 

T1 j 

l 

1 1 

244 | 251 j 

1 9 

659 | 

1 

250 j 

i 

1 

252 j 

1 

229 j 

304 

1 1 

1 313 | 

i i 


T2 j 

1 

1 1 
421 j 428 j 

i i 

1 

823 | 

i 

1 

427 | 

i 

1 

431 | 

450 | 

475 

1 1 

1 478 | 

1 1 


1 

T3 j 

1 

1 1 
110 j 114 j 

i i 

1 

504 j 

114 j 

I 

1 

114 j 

1 

129 j 

l 

137 

1 1 

1 164 j 

l 1 


1 

T4 j 

l 

1 I 

154 | 160 j 

l i 

1 

783 | 

i 

1 

161 j 

i 

161 | 
i 

179 j 

181 

1 1 

j 211 | 

1 1 


1 

T5 j 

1 

101 | 105 j 

i i 

1 

701 j 

i 

1 

106 j 

i 

1 

106 j 

121 j 

i 

127 

1 1 

1 154 j 

l l 


i 

T6 j 

i i 

404 j 411 j 

i 

813 | 

i 

410 j 

i 

411 j 

i 

431 | 

459 

I 1 

1 462 | 

^ T— 4- 


VAX/VMS X4.6 on node ll-NOV-1987 

09:41:39.79 Uptime 0 13:19:19 




Pid 

Process Name 

State 

Pri 

I/O 

CPU 


Page fits 

Ph.Mem 

00000080 

NULL 

COM 

0 

0 

0 12:40:39.52 

0 

0 

00000081 

SWAPPER 

HIB 

16 

0 

0 00:00:00.21 

0 

0 

00000091 

CTXSW1 

CUR 

25 

8997 

0 00:15:11.46 

16835 

428 


System Service Timing Test Sequence 

• Lock process’s PO space into memory to prevent paging 

• Map I/O page into process space for direct I/O 

• Initialize data structures 

• Top of loop: 

a) Start the clock 

b) Perform system service 

c) Stop clock and record the time 

d) Repeat steps (a)-(c) for each system service 
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• If loop count > = the number of iterations for this test, then exit; else return to top of the loop 
System Service Timings 

• Test system A 

• base IPL = 0 

• SW priority = 18 

1,000,000 data points. Test time = 01:16:09.74 


VAX/VMS X4.6 on node 20-NOV-1987 08:26:49.93 Uptime 0 00:17:19 


Pid 

Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 

00000020 

NULL 

COM 

0 

0 

0 00:15:25.97 

0 

0 

00000021 

SWAPPER 

HIB 

16 

0 

0 00:00:00.18 

0 

0 

0000002D 

GAUTHIER 

CUR 

18 

389 

0 00:00:09.60 

1349 

347 



MIN 

MEAN 

MAX 

MODE 

95.0% 

99.0% 

99.5% 

99.9% 

NULL | 

i 

36 | 

I 

36 

1 

1 

876 

1 

1 

37 

1 

1 

36 | 

36 | 

i 

40 | 

i 

103 | 

1 

SYS$SETEF | 

1 

1 

202 | 

I 

204 

1 

1 

1 

1086 

1 

1 

202 

1 

1 

1 

204 j 

i 

1 

258 | 

l 

260 j 

l 

332 | 

1 

SYS$CLREF j 

1 

1 

140 | 

141 

1 

1 

1 

979 

1 

1 

1 

141 

1 

1 

I 

1 

140 j 

1 

1 

194 j 

1 

1 

196 | 

264 | 

SYS$READEFj 

149 | 

151 

1 

1 

1 

1022 

1 

1 

150 

1 

1 

I 

150 | 

204 | 

208 | 

278 | 

SYS$SETIMR| 

322 | 

328 

1 

1 

1208 

1 

1 

326 

1 

1 

1 

330 | 

1 

384 | 

1 

386 | 

464 | 

1 

SYS$CANTIMj 

284 | 

290 

1 

1 

1 

1174 

1 

1 

288 

1 

1 

1 

1 

290 j 

344 j 

i 

348 | 

1 

428 | 

1 

1 

SYS$SCHDWK j 

316 | 

1 

323 

1 

1 

1 

1696 

1 

1 

1 

320 

1 

1 

1 

322 | 

I 

1 

378 j 

l 

382 | 

460 | 

1 

SYS$CANWAK| 

1 

1 

286 j 

i 

296 

1 

1 

1 

1156 

1 

1 

1 

294 

1 

1 

1 

1 

294 | 

I 

1 

350 j 

i 

354 | 

I 

434 | 

1 

SYS$SETPRI| 

1 

221 | 

224 

1 

1 

1608 

1 

1 

222 

1 

1 

224 j 

1 

279 j 

1 

283 | 

356 | 


+-+ 


VAX/VMS X4.6 on node 20-NOV-1987 09:42:59.67 Uptime 0 01:33:29 


Pid Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 

00000020 NULL 

COM 

0 

0 

0 00:15:29.87 

0 

0 

00000021 SWAPPER 

HIB 

16 

0 

0 00:00:00.18 

0 

0 

0000002D GAUTHIER 

CUR 

25 

493 

0 01:16:15.26 

2368 

349 

System Service Timings 







• Test system B 

• base IPL = 0 







• SW priority =25 







1,000,000 data points. Test time = 

00:27:14.82 




VAX/VMS X4.6 on node ll-NOV-1987 

14:11:58.63 Uptime 0 04:28:33 



Pid Process Name 

State 

Pri 

I/O 

CPU 

Page fits 

Ph.Mem 
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00000080 

NULL 


COM 

0 

0 


0 04:09:18.96 

0 

0 

00000081 

SWAPPER 

HIB 

16 

0 


0 00:00:00.14 

0 

0 

0000008E 

GAUTHIER 

CUR 

18 

1002161 

0 00:13:55.16 

8777 

347 



MIN 

MEAN 

MAX 

MODE 

95.0% 

99.0% 

99.5% 

99.9% 


NULL 


1 9 

1 12 | 
1 1 

355 

1 12 | 

1 i 

12 

1 

1 

12 | 

1 

12 | 

33 | 


SYS$SETEF 


| 70 

I 

1 1 
1 77 | 

i ii 

481 

1 1 

j 77 j 

i i 

78 

1 

1 

79 | 

i 

97 j 

i 

1 

99 j 

i 


SYS$CLREF 


1 

1 41 

l 

1 i 

1 A3 | 

1 1 

392 

1 1 

j 43 j 

i i 

44 

1 

1 

1 

48 j 

i 

50 | 

1 

66 j 

1 


SYS$READEF 


1 

j 46 

l 

1 ! 
1 50 | 

1 

396 

1 1 

j 50 j 

i i 

50 

1 

1 

1 

1 

52 j 

i 

1 

55 j 

I 

74 j 

i 


SYS$SETIMR 


1 

| 119 

1 129 | 

539 

1 1 

1 128 | 
i i 

130 

1 

1 

150 j 

i 

153 | 

155 j 


SYS$CANTIM 


| 98 

1 

1 1 
1 109 j 

! 

455 

1 1 

j 109 | 
i i 

110 

1 

1 

1 

130 | 

i 

131 j 

i 

1 

134 j 

i 


SYS$SCHDWK 


1 

| 114 

l 

1 126 | 

757 

1 1 

1 126 | 
i i 

128 

1 

1 

1 

147 | 

i 

148 j 

1 

150 j 

i 


SYS$CANWAK 


1 

| 94 

| 109 | 

1 i 

453 

1 1 

1 109 | 

i i 

110 

1 

1 

1 

1 

128 j 

i 

130 | 

i 

1 

133 j 


SYS$SETPRI 


| 80 

1 ! 
1 93 | 

495 

1 1 

1 93 | 

94 

1 

1 

1 

94 | 

1 

112 j 

114 | 

i 


VAX/VMS X4.6 on node ll-NOV-1987 14:39:13.45 Uptime 0 04:55:48 




Pid 

Process Name 

State 

Pri 

I/O 


CPU 

Page fits 

Ph.Mem 

00000080 

NULL 


COM 

0 

0 


0 

04:09:20.86 

0 

0 

00000081 

SWAPPER 

HIB 

16 

0 


0 

00:00:00.14 

0 

0 

0000008E 

GAUTHIER 

CUR 

25 

1002254 

0 

00:41:08.05 

9891 

356 


DAR-18 












The Wombat 


EXAMINER 

‘‘Increases the Circulation of Anyone in America” 


attft 4(£2I 

Sispatrtf 

Volume 9 Number 11 









Contributions 

This newsletter is a volunteer activity. There are no compensations given to any author or editor. Articles and 
letters for publication are encouraged from anyone. They may include helpful hints, inquiries to other users, 
reports on DECUS and SIG business, summaries of SPRs submitted to Digital, or any information of interest to 
users of either DATATRIEVE or 4th Generation Languages. However, this newsletter is not a forum for job 
and/or head hunting, nor is commercialism appropriate. 

Machine readable input is highly desirable and machine-to-machine transfer of material is preferred, but most 
anything legible will be considered for publication. 

Please send contributions, or for further information please contact either: 

Editor, DATATRIEVE Newsletter Joe H. Gallagher, Ph.D. 

c/o DECUS U.S. Chapter 4GL Solutions 

Company 219 Boston Post Road, BP02 10308 Metcalf, Suite 109 

Marlboro, MA 01752 Overland Park, KS 66212 

Editorials and letters to the editor within the Wombat Examiner and 4GL Dispatch are solely the opin¬ 
ion of the author and do not necessarily reflect the views of the Digital Equipment Computer Users So¬ 
ciety, Digital Equipment Corporation, or the author’s employer. All editorials are marked as “An Edi¬ 
torial”; letters to the editor always begin “Dear Editor”. 
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Letters to the Editor 


Dear Editor of the Wombat Examiner & 4GL Dispatch: 

I am looking for any one with experience using DATATRIEVE and CMS together. We are currently developing 
a moderate size decision support system using large DATATRIEVE summarization and reporting procedures. Our 
normal development practices include the use of CMS. Using CMS in the DATATRIEVE development environ¬ 
ment is proving less friendly than in a 3rd generation development environment. I can be reached at the GE 
Lighting, Nela Park, Cleveland, Ohio. My phone is 216-266-8588. 

Bill Wood 

Dear Editor of the Wombat Examiner & 4GL Dispatch: 

An Application Factory (Cortex) Working Group of the DATATRIEVE/4GL SIG is in the process of being 
formed. Anyone interested should contact: 

Eric S. Dubiner 
duPont 

Information Engineering Associates 
Nemours Building TFD, Suite 9510 
Wilmington, DE 19898 
302-773-6780 or 302-773-6785 


Dear Wombat Wizard 

Joe H. Gallagher, Research Medical Center, Kansas City, MO. 


Dear Wombat Wizard: 

I am running a menu-driven application in DATATRIEVE and I would like to disguise the fact that I am using 
DATATRIEVE. How do I get rid of the DATATRIEVE startup banner? The startup banner looks like: 

VAX Datatrieve V4.X 

DEC Query and Report System 

Type HELP for help 


Signed, 

The DTR Disguiser 


Dear Disguiser: 

There are two ways to solve your problem: the first is quick and dirty and the second is really the right way. 
First, the cute way. Include in your DTRSSTARTUP command file the following: 

OPEN TT: 

Then reassign your SYSSOUTPUT to the “bit-bucket” (the 
null device) and start DATATRIEVE like: 


DTR-2 



$ define/user sys$output nl: 

$ run sys$system:dtr32 
DTR> 

This will start DATATRIEVE without the startup banner, but if you live at the DTR> prompt, you’ll see the 
prompt and command twice. 

The “right” way to disguise DATATRIEVE is to 

1. Copy DTR$LIBRARY:DTRMSGS.MSG to your application’s source directory. 

2. Edit DTRMSGS to remove the offending message text, or replace it with something else. The 
startup message is at .BASE 171 SIGNON. You might also want to change some other messages 
to make them more customized for your application. For example, if your application sometimes 
generates messages like “Can’t take MAX, MIN, or AVERAGE of zero objects” you might 
change it to be “There aren’t any YACHTS to find the average price for!” Just be careful not to 
change the number or type of substitution directives (the !xx parameters in the messages). 

3. Compile and link the message source file. Place the resulting .EXE in your application’s run-time 
directory if you want only your application affected. Or replace DTRMSGS.EXE to change the 
messages for DATATRIEVE for the whole system. The DATATRIEVE documentation discusses 
compiling the message file, but the basic idea is this: 

$ MESSAGE/LIST DTRMSGS 

$ LINK/SHAREABLE=my__di r : DTRMSGS DTRMSGS 

4. In the command file which runs the application, include the assignment of the logical DTRMSGS 
which points to the new message file. 

$ DTR :== $DTR32 

$ DEFINE/USER DTRMSGS my__dir: DTRMSGS 

$ DTR 

You could also change the startup message in DTR-11 by changing LB:[1,2]QUERY.MSG by editing the 
MSGS.SEQ file that came on the distribution kit. In any case, this should allow you to disguise the fact that you 
are using DATATRIEVE by hiding the DATATREIVE startup banner. 

Signed 
The Wizard 


Product Status Report 

Lorey B. Kimmel, Associate Newsletter Editor, Baltimore, MD. 


The following is a list of Digital Equipment Corporation software products of interest to the DATATRIEVE/Fourth 
Generation Language Special Interest Group. Although it is not totally complete, at least you can use this list to 
have some idea of what products were released when. 


Product 

Version 

Announce 

Prerequi 



Date 

Software 

VAX DATATRIEVE 

4.1 

11/87 



4.0 

2/87 



3.4 

6/86 

VMS 4.4 


3.3 

11/85 

VMS 4.2 


3.2 

5/85 

VMS 4.0 
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Product 

Version 

Announce 

Prerequisite 



Date 

Software 

DATATRIEVE 11 

3.2 

11/87 



3.1 

8/84 

RSTS 9.0 

RSX 4.1 

RSX+ 2.1 

Micro RSX 1.1 
VMS 4.0/RSX 1.0 
Micro RSTS 1.0 

DECreporter 

to 

O 

2/87 



1.1 

4/86 

VMS 4.3 


1.0 

11/85 

VMS 4.2 

VAX TEAMDATA 

1.2 

12/87 

VMS/Rdb 


1.1 

2/87 


VAX RALLY 

1.1 

1/87 

VMS/Rdb 


Spring 1988 DECUS Update 


Pat Scopelliti, Associate Newsletter Editor, Corning Glass Works, Corning, NY 


The 1988 Spring DECUS in Cincinnati was another enjoyable, but work filled event. Here are some of the 
significant events from the symposium. 

Don Stern officially took over the office of DTR/4GL SIG Chairperson, replacing Joe Gallagher. Joe was pre¬ 
sented with some gifts from the SIG in appreciation of his outstanding term as SIG Chair. The SIG will still have 
Joe’s services; he is taking over the duties of Newsletter Editor. 

Some new by-laws were also adopted by the SIG at the Friday afternoon Steering Committee Meeting during the 
symposium. The new by-laws provide for the office of Vice-Chairperson who will assist the Chair, represent the 
SIG in the absence of the Chair, and serve as Chairperson in the event of a vacancy in the Chair’s office due to 
resignation or incapacity. The by-laws also formally create the positions of Working Group Chair, Working Group 
Coordinator and Volunteer Coordinator. These positions were in common use, but were not officially recognized 
until now. 

Working Group Chairs and their Counterparts met as a group for the first time during the symposia. Present were 
representatives from the Accent-R, PowerHouse, FOCUS, Oracle, SmartStar, and RALLY Working Groups. 

On the software front, notable by its absence was the anticipated next version of DATATRIEVE and companion 
products. However, if one logged in to the cluster in the demonstration hall, CDD+ (Version 4.0) was found tobe 
running. Obviously, this was a portend of things to come. 

The SIG Steering Committee also tentatively scheduled the next Woods meeting for the Boston area on August 
18-20. 
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Developing Applications in DATATRIEVE; Style and Convention 

Joe H. Gallagher, Ph. D., 4GL Solutions, Overland Park, KS 66212 

Within the framework of the DATATRIEVE language where keywords and language syntax is specified, a pro¬ 
grammer has a great deal of freedom to influence the readability and maintainability of created dictionary objects 
and DATATRIEVE code. This freedom is mostly vested in the naming of elementary and group fields and 
dictionary objects (domains, records, tables, procedures, and plots). But this freedom extents to the naming of 
files and even to the formatting (or non-formatting) of nested compound statements. 

Field Names 

As examples of how the naming of elementary and group fields affects the readability and usability of- 
DATATRIEVE, consider three essentially equivalent record definitions. The first record definition is as follows: 

define record ml-rec using optimize 
01 ml-rec. 

03 In pic x(18). 

03 fn pic x(12). 

03 mi pic x. 

03 al pic x(30). 

03 a2 pic x(30). 

03 ct pic x(15). 

03 st pic x(2). 

03 zp pic 9(5). ; 

The programmer of this first record definition learned BASIC about 10 years ago when only two character names 
where allowed (and maybe hasn’t learned anything more since). Certainly the programmer is a very poor typist; 
he can’t type more than two characters at a time without making a mistake. While the record definition is 
technically correct, procedures using this record definition are unlikely to be easily readable. 

The second record definition is: 

define record mailing-list-record using optimize 
01 mailing-list-rec. 

03 mailing-list-last-name picture x(18). 

03 mailing-list-first-name picture x(12). 

03 mailing-list-middle-initial picture x. 

03 mailing-list-address-linel picture x(30). 

03 mailing-list-address-line2 picture x(30). 

03 mailing-list-city picture x(15). 

03 mailing-list-state-code picture x(2). 

03 mailing-list-zip-code picture 9(5). ; 

The mother of the programmer of this second record definition was obviously frightened by a COBOL compiler. 
Procedures written with this record definition are verbose and unwieldy; column headers look peculiar. Joining 
this domain with others is absolutely clear, but certainly interminably long. It is also clear that the programmer of 
this record definition does not type at all. If he had to type and use such long field names,they would certainly be 
shortened. 

The third record definitions is: 
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define record mailinglist-record using optimize 
01 mailinglist-rec. 

03 name. 

05 last-name pic x(18). 

05 first-name pic x(12). 

05 middle-init pic x 

valid if middle-init = " " or 
middle-init bt "A” and "Z". 

05 print-name computed by choice of 

middle-init eq " " then first-name ||| last-name 
else first-name ||| middle-init |". "| last-name 
end-choice edit-string is x(34). 

03 addressl pic x(30). 

03 address2 pic x(30). 

03 city pic x(15). 

03 state-code pic x(2) 

valid if state-code in state-code-table. 

03 zip-code pic 9(5). 

03 print-citystatezip computed by 
city)|", "|state-code|" "| 

format zip-code using 9(5) . ; 

Now, as you might have guessed, this third record definition was written by a DATATRIEVE programmer. The 
field names are of modest length, but completely and accurately describe the field. Validation clauses are in¬ 
cluded on MIDDLE_INIT and STATE_CODE; conveniently formatted composit print buffers, PRINT_NAME 
and PRINT__CITYSTATEZIP, are included in the record definition. 

It is amazing how different in appearance and functionality these three essentially identical records are! 

Domain names 

Now consider the naming of domains. Since the name of the domain is the object or “target” of many statement 
or command verbs, selecting a domain name which is a plural noun creates the most natural syntax in 
DATATRIEVE. YACHTS, OWNERS, FAMALIES, PETS, and EMPLOYEES are some of the familiar example 
domains used in DATATRIEVE documentation. Most DATATRIEVE programmers do observe this domain 
naming convention. There is one notable exception to this convention. Where a plural noun which describes the 
contents of the domain has a singular equivalent, this equivalent is sometimes used as the domain name and 
describes the aggregation of “things” in the domain. An example of this would be the one used above, 
MAILINGLIST. Following the normal naming convention one would used NAMES_AND_ADDRESS rather 
than MAILINGLIST; but names and address make up the mailing list (i.e, the mailing list is the aggregation of 
names and address). 

Violating the standard naming convention with something like: 

define domain QUICK using yachts-record on yachts.dat; 
gives peculiar DATATRIEVE statements like: 
ready QUICK 

for QUICK with loa gt 12 


Using a part of speech other than a noun (or perhaps a possessive pronoun like MINE, YOURS, OURS, etc) 
spoils the English-like syntax of DATATRIEVE and certainly gives little indication as to the contents of the 
domain. 
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Record names and top-level group field names 

The choice of a record name is probably the least important naming choice that a DATATRIEVE programmer 
makes. The record name appears only in the domain definition and the record definition; it is used no where else 
in DATATRIEVE. The only real necessity is that the name be chosen in a non-confusing way. A name such as 
YACHTS-TABLE would be a poor choice for a record name. My preference for a record name is to use the 
name of the domain followed by “-RECORD”. By appending “-RECORD” it is absolutely clear that it is a record 
definition. 

Unlike the record name, the top-level group field name is frequently used when restructuring a domain and 
sometimes in print statements. Examples in Digital’s documentation usually name the top-level group field as 
either the domain name or the record name, but the well-known example of YACHTS is an exception where the 
record name is YACHT and the top-level group field is BOAT. The Application Design Tool (ADT) names both 
the top-level group field and the record name as the domain name followed by “-REC”. I prefer to give the 
top-level group name a name which is different from both the domain and record name. Like ADT, I prefer to 
use the domain name followed by “-REC”. When initially learning DATATRIEVE (several years ago), I was very 
confused by the lack of convention in naming domains, records, and (particularly) top-level field name. While 
the name conventions I have described are certainly not the only possible ones, I have found them to be relatively 
easy for beginning DATATRIEVE users to grasp. 

Table names 

Table names can be any unique name, but I have always found it least confusing if the table name contains the 
word “TABLE.” Such table name as STATE_CODE_TABLE or TITLEJ3F_ADDRESSj:ODEjrABLE pro¬ 
vide clear indication of the contents of the table and an almost natural syntax when used in a print or validation 
statement such as 

print state-code via state-code-table 


or 


03 state-code pic x(2) valid if state-code in state-code-table. 

Hierarchy names 

Many DATATRIEVE programmers bitten with the “relational bug” try to avoid using hierarchies such as views. 
But the data structure of lists or one master record with a variable number of detail records occurs very often in 
many kinds of applications. The syntax of accessing fields that are in lists is certainly not a trivial as accessing 
non-hierarchical fields. However, some (if not most) of the difficulties are resolved by choosing appropriate 
names for the lists and list elements. Consider the following record definition for a domain named PATIENTS: 

define record PATIENTS-RECORD using optimize 
01 patients-rec. 

03 name pic . . . 

03 number_of_diagnoses usage is byte 

valid if number_of_diagnoses between 0 and 9. 

03 diagnoses occurs 0 to 9 times depending on 
number_of_diagnoses. 

05 diagnosis pic x(n). 


By naming the list as a plural noun (just as we did with domains) and the elements of the list as singular nouns, we 
create the most natural DATATRIEVE syntax for referring to heirarchies. In this case, a record selection expres¬ 
sion and a print statement would look like: 
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find patients with any diagnoses with 
diagnosis = "flat feet" 

print name, all diagnosis of diagnoses of current 

When it comes to naming the list in a view, I depart from my own convention. Rather that use a record definition 
like: 

DEFINE DOMAIN SAILBOATS OF YACHTS, OWNERS BY 
01 SAILBOAT OCCURS FOR YACHTS. 

03 BOAT FROM YACHTS. 

03 SKIPPERS OCCURS FOR OWNERS WITH TYPE EQ BOAT.TYPE. 

05 NAME FROM OWNERS. 


My preference for the view definition would be: 

DEFINE DOMAIN SAILBOATS OF YACHTS, OWNERS BY 
01 SAILBOAT-REC OCCURS FOR YACHTS. 

03 BOAT FROM YACHTS. 

03 OWNERS-R OCCURS FOR OWNERS WITH TYPE EQ BOAT.TYPE. 
05 NAME FROM OWNERS. 


I prefer a list name like OWNERS-R to SKIPPERS since it is not completely clear that SKIPPERS is a list of 
OWNERS. 


Formatting 

Formatting procedures and record definitions improved the readability of the code or definitions. I have a strong 
preference that procedures should be indented four spaces for each level on nesting. Such code would look 
something like: 


for foo begin 

if ( . . . ) then begin 

statements 
end else begin 
more statements 
end 

end 

If the number of levels of nesting is very large, then two spaces of indention for each level should be more 
practical. 

For record definitions, I preference three spaces of indention. A record definition would then look like: 

define record foo-record using optimize 
01 foo-rec. 

03 first-foo-field ... 

03 second-foo-field ... 

03 group-field. 

05 first-group-field . . . 
first clause on field 
second clause on field 
last clause on field. 
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By using three space of indention, one space between the level number and the field specification, and indenting 
the clauses under the field specification, the resulting record definition is readable and maintainable. 

I am not suggesting that the style and conventions which I have described here are the only way or even the best 
way of writing code and definitions in DATATRIEVE. It is a way that works for me; you should find what works 
best for you. 


RECORD-LEVEL SECURITY IN A VAX RALLY APPLICATION 

DAVID M. FOSTER, Digital Equipment Corporation, Continental Blvd. (MK02-1/J12), 

Merrimack NH, 03054 


Abstract: 

VAX RALLY is a fourth generation application development system from Digital Equipment Corporation. 
This article is part of a series that describes special techniques that customers have found useful when 
developing applications with RALLY. This article explains a security scheme for protecting data from 
unauthorized users. 


Introduction 

This article describes a method for providing one kind of security for data accessed through a RALLY application. 
This method handles situations where several users need access to certain records in a relation, but must be 
denied access to other records in that relation. We will use a simple personnel application as an example. The goal 
is to allow each manager to read and update records for his/her own department(s), but not for other depart¬ 
ments. We do not assume that each manager is in charge of only one department. 

In the past, we have recommended using Rdb/VMS views to solve this problem. However, when multiple views 
refer to a single Rdb relation, the RALLY application must contain a DSD and a form/report for each view. There 
must also be a mechanism to direct each user to the correct form/report and block him/her from the others. For 
even a small number of users, this clutters the application. It also makes maintenance almost impossible. When 
the responsibilities of a manager change, for instance, you may have to create new views, DSDs, and Form/Re¬ 
ports (F/Rs) or change old ones. When one form/report changes, all the form/ reports that perform the same 
function on other views must also be changed. 

The solution proposed here requires only a single DSD. In summary, the mechanism is as follows: 

1. Create the DSD. 

2. Write an external link program to obtain the username from the system and assign it to a global 
variable. Execute this program at application startup. 

3. Create a relation in the database with two fields: 

o The first field is the name of a user. The username here should match a username on the 
system. 

o The second field is the identifying key of a record that user is allowed to access. 

We call this the security relation. 
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4. Use the security relation as a “filter” to determine which records are retrieved for each type of 
form/report in the application: 

o For query mode forms, create a subset list of values (LOVs). The LOV retrieves only the 
records from the security relation where the username matches the current username. It 
displays the corresponding key values. You use this LOV to validate the key field in the 
query screen. That is, when users want to query the database, the LOV limits them to 
only the key values for records they are allowed to see. 

You must also make this key field required on queries. A technique for doing this is described later. 

o For update mode forms, use the security relation as the parent group and perform a query 
initially, using the current username. The result is a child group containing only the re¬ 
cords the user is allowed to see. Disallow query on this screen. Note that in a simple 
application, you might not need an update screen. Users can update through the query 
form. 

o The insert mode form can use a subset LOV, as in the query form. That is, a user can 
enter a new record only if the record’s key field value is linked with that user’s name in 
the security relation. 

The result is a kind of Access Control List internal to the RALLY application. However, with traditional ACLs or 
passwords, users receive an error message when they try to access forbidden data. With this solution, users never 
see error messages and are never told explicitly that there are records in the database that they are not allowed to 
see. 

The example that follows shows how this solution might be implemented. The sample application uses a modified 
version of the EMPLOYEES relation in the PERSONNEL database, which is shipped with each Rdb/VMS kit. 
EMPLOYEES has been changed to include a DEPARTMENT^ CODE field, to avoid too many levels of joining. 
The values for DEPARTMENT_CODE were copied over from JOB_HISTORY, where the department ID for 
each employee’s current job is stored. The idea is to allow each manager to see only the employees in his/her 
department. 

We use the username to retrieve a subset of the security relation. Then we use the records retrieved from the 
security relation to retrieve the corresponding subset of employee records. The usernamed FOSTER sees only the 
records marked with asterisks. 


Username 


Security 

Relation 


Employees relation 

FOSTER 

-+ 

1 

Name 

Dept. 


Id 

Name 

Dept. 


1 

+-> 

♦FOSTER 

ELEL-+— 

-> 

*00015 

Jones 

ELEL 


+-> 

♦FOSTER 

SALE-+— 

-> 

*00017 

Gore 

ELEL 



MCKIM 

SPMG +— 

-> 

*00019 

Jackson 

SALE 



MCKIM 

ADVD +— 

-> 

*00034 

Duke 

SALE 






00047 

Bush 

SPMG 






00076 

Hart 

ADVD 






00089 

Dole 

ADVD 


In this example, the user’s name is not a field in the relation that the user wants to see. If it were, the problem 
would be much simpler. This case will be discussed later. 

Each section of this article describes one of the steps in implementing the technique. 

Creating the SECURITY Relation, Form/Reports, and DSDs 

This section describes how to create the SECURITY relation, along with the basic DSDs and form/reports for the 
application. 
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1. Create a new relation called SECURITY in the database. This relation has two fields: 


USERNAME — Datatype text, size 12 
DEPARTMENT_CODE — Datatype text, size 4 

2. Create three DSDs: 

o Create two DSDs for the SECURITY relation: 

- SECURITY_READ_DSD, marked for READ ONLY access 

- SECURITY_WRITE_DSD, marked for SHARED WRITE access 

o Create a DSD for the EMPLOYEES relation, EMPLOYEES__DSD. Make this a 
SHARED WRITE DSD. 

In this DSD, place the key field, DEPARTMENT^ CODE, first in the order of the fields. 
This will be important later. Do this by entering “Y” the field that asks if you want to edit 
the list of fields in the DSD. Delete DEPARTMENT^ CODE from its original position and 
use ’insert record before’ to place it first. 

3. Using the Builder Tools, create three form/reports: 

o EMPLOYEES_FR—a single-group form/report to be used for insert and query. The G1 
group of this form/report points to the EMPLOYEES__DSD. 

o EMPLOYEES_UPDATE_FR—a two-group form/report: 

- The parent group is based on SECURITY_READJDSD. Mark this group DOES NOT 
REPEAT. 

- The child group is based on EMPLOYEES_DSD. Mark this group labels ABOVE, 
repeats DOWN. 

- The two groups are linked by the DEPARTMENT__CODE field. 

o SECURITYJFR—a single group form/report pointing to the SECURITY_WRITE_DSD. 

A privileged user (database administrator or senior manager) uses this form/report to 
update the security information. 

4. Use the Editing Environment to edit the USERNAME field in the EMPLOYEES_UPDATE_FR. 
Mark the USERNAME field non- displayed (path 7 7 1 under Edit a Field’s Attributes). That is, 
the user sees the parent key, DEPARTMENT_CODE, but not his or her own name. At the same 
time, edit the image for the EMPLOYEES_UPDATE_FR to eliminate the label for the USER- 
NAME field. 

5. Define the main menu for the application using the Menu Builder: 


Form/Report 

Mode 

EMPLOYEES_FR 

INSERT 

EMPLOYEE S_UPDATE_FR 

QUERY 

EMPLOYEES_FR 

QUERY 

SECURITY FR 

BUD 


Note that the update form/report should be marked to be brought up in QUERY mode. You will execute a query 
initially, before the user sees the data, so you need to begin in QUERY mode. When the user sees the form, it will 
be in BUD mode. 
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Eventually, you should remove SECURITY_FR from the menu and hide it under another menu/task or in another 
application file, protected from end users. 


Subsetting Data using a Subset List of Values 


At this point, you have a skeleton for the application, but every user can see all the records in the EMPLOYEES 
relation. Now you must add a mechanism to each form/report to create a subset of the data. 

1. Define a global variable USERNAME to hold the current user name from the system. You will 
assign a value to this variable using an external link. 

2. Create a list of values group in the SECURITY__FR called SECURITY_LOV_GRP. 

3. Create two fields in SECURITY FR: 


o DEPT—based on the SECURITY_READ_DSD field, SECURITY_DEPART 

MENT_CODE. Name of parent group is SECURITY_LOV_GRP. 

o USERNAME—MAKE THIS A COPY FIELD. That is, choose 5 from the Create a 
Form/Report Field menu. The value for the field is copied from the global variable that 
contains the current username. This value is used to trigger an implicit query on the 
LOV’s data source. When the LOV appears, only the records from the SECURITY 
relation that match the current username will be included in the LOV. If you are unfamil¬ 
iar with subset LOV (sometimes called dependent LOV) note the following attributes 
carefully: 

Name of parent group? SECURITY_LOV_GRP 


Store field in data source? 

Name of DSD 

Name of DSD field 


Y [VERY IMPORTANT!] 
S ECURITY_READ_DSD 
SECURITY USERNAME 


Source for copy field: 

Field Type 
Field Name 


GLOBAL VARIABLE 
USERNAME 


When asked to mark the field’s location, make the field non-display. 

o IMPORTANT: Under 7 - Edit additional attributes, choose 4 - Query by example attrib¬ 
utes. This form lists operations NOT to perform in QUERY mode. Remove the X from 
the first attribute, Compute/Copy. (That is, “DO fill in computed fields and copy fields 
when the form is in QUERY mode”.) Because the subset LOV mechanism involves a 
query, you must allow a copy field to be filled in when the form/re port is in query mode. 

4. You have created the LOV that will bring up a subset of the SECURITY relation. That is, if the 
current username is FOSTER, the LOV will include the department codes for the departments 
that FOSTER manages. You want to attach this LOV to the DEPARTMENT_CODE field on the 
EMPLOYEES__FR. When you do, it will appear on both insert and query. On insert, it will force 
the manager to enter new employees only in the departments that s/he manages. On query, it will 
force the manager to enter one of his/her departments as a one of the conditions for the query. 

5. Edit the EMPLOYEES_FR and the field Gl_EMPLOYEES_DEPARTMENT_CODE. Under 7 - 
Additional attributes, choose 3 - List of values attributes. On the list of values attributes form, 
mark two fields: 
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o Display list of values when cursor enters field 
o Validate this field against the list of values 
For the source of the List of values, specify: 


Type of List of Values: 
List of Values context: 
List of Values field name: 


FIELD 

SECURITY_FR 

DEPT 


NOTE 

Do not choose to have the cursor enter the list of values automatically. This will 
trigger a bug that will leave a hole in your security scheme. 

Subsetting Data using a Before-Form/Report Query 

Now you have created the subset LOV and attached it to the DEPARTMENT_CODE field in the EMPLOY- 
EES_FR, which is used for both insert and query. Now you want to perform a similar subsetting operation on the 
update form, EMPLOYEES_UPDATE_FR. This is much simpler: 

1. Edit the form/report packet associated with EMPLOYEES_UPDATEJFR to disallow queries. 
Although this form/report is marked to be opened in query mode, it will be in BUD mode when 
you user sees it. 

o Take menu path 5 2 8 2. 

o The name of this packet will be EMPLOYEES_UPDATE_FR_QUERY_PKT. 

o Choose 6 - Additional options. 

o Mark X in the Query not allowed field. This does not disallow queries, but rather prevents 
the user from issuing the ’set query’ command. 

2. Write an ADL procedure, CALL_EMPLOYEE_FORM, that looks like this: 

EMPLOYEES_UPDATE_FR.G1_SECURITY_USERNAME USERNAME; CALL_CMD(QUERY); 

Remember, the parent group of this form report is based on the SECURITY relation. This procedure 
assigns the current username, stored in the global variable USERNAME to the G1_SECU- 
RITY_USERNAME field in the parent group and then performs a query. As a result, the only 
records on the screen are those whose department code value is associated with the current user 
in the SECURITY relation. If user FOSTER manages two departments, ELEL and SALE, FOS¬ 
TER will see two parent records and their associated children, the employees in the ELEL and 
SALE departments. Because the parent group is derived from the SECURITY_READ_DSD, 
which is a READ ONLY DSD, and because the key field in a child group is marked non-dis- 
played, FOSTER cannot change the department code value. 

3. Now attach this ADL procedure to the application by associating it with the form/report packet 
that calls the EMPLOYEES_UDATE_FR. Menu path 5 2 8 2 lets you edit a call packet. Choose 
2 on the packet editing menu - before/after events: 

Before form/report: 
call type: CALL 
item type: ADL PROCEDURE 
item name: CALL EMPLOYEE FORM 
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As mentioned in the beginning, if the user’s name is a field in the relation, the problem is simpler. No security 
relation is necessary. For example, assume that the employee relation has a field containing the manager’s name. 
To subset the relation, you simply get the current username and use it to drive a query that brings up the form’s 
data, as described in this section. On insert, you can fill in the field automatically from the current username; on 
update, you can prevent the cursor from entering the field. This will guarantee that a user cannot enter an 
unauthorized username. 


Assigning the username to a Global Variable 

At this point, you have implemented two methods for subsetting the data. Both use a global variable that contains 
the current username. Now you must assign a value to that global variable by getting the user name from the 
system. To do this, you need to define an external link. 

1. First, write a program that calls LIBSGETJPI to get the current username. A sample COBOL 
program that does this is included at the end of this article. Compile and link the program using 
the linker options file, as described in the ADL User’s Guide. 

2. Create an external link USERNAME_LINK. For the number of this link, use the same number 
that you encoded in your program. In the sample program, the variable called “action” is the 
number of the link. 

3. Define a parameter for the link, as follows: 

Parameter number: 1 

Parameter type: GLOBAL VARIABLE 
Context name: 

Field name: USERNAME 

Offset in parameter packet: 0 

Read or Write designation: WRITE ONLY 
Format type: STRING 
Length of string: 12 

4. Now you have written the program that gets the username, and you have created the external link 
within the application. The final step is to attach the link to the application by calling it from an 
action site. Because you will need the global variable from the beginning of the session, attach the 
link as a before menu action on the main menu (menu path 5 12 [MAINJMENU] 4). 

$ RALLY RUN APPLICATION 

I 

V 

CALL USERNAME_LINK [USERNAME := FOSTER] 

I 

V 

CALL MAIN_MENU 

When FOSTER runs the application, the USERNAME global variable is FOSTER from the beginning, and FOS¬ 
TER is the value that subsets the DEPARTMENT records and the List of Values. 

Final Touches 

One final problem: when you execute a query in RALLY with no fields filled in, RALLY retrieves all the records 
called for by the DSD. Assume the user has chosen the query form. When s/he presses the FIND key, all the 
records from the relation appear, including those that are supposed to be hidden from this user. Making the 
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DEPARTMENT_CODE field a required field does not solve the problem; RALLY does not require the field to be 
input on a query screen, even if you have marked it as required. This is a problem only if you intend to allow 
interactive queries. 

To solve this problem, you must do two things: 

1. Make the field first on the input order of the form/report, so the cursor must visit the field. That 
is why you put the DEPARTMENT_CODE field first in the DSD. If you had not, you would have 
to change the input order of the form/report to make the DEPARTMENT_CODE field first. 

2. Write an ADL routine to make this field required. Attach the ADL routine as a after-field action 
on Gl_EMPLOYEES_DEPARTMENT_CODE. Now the user must enter a value for DEPART- 
MENT_CODE, even when doing queries. Furthermore, the valid DEPARTMENT__CODE values 
are always available in the LOV, and the LOV is used for validation. Because the LOV is the 
user’s own subset, the user can never choose an unauthorized DEPARTMENT_CODE. 

The routine might look like this: 

{Test to see if the field is empty.} 

IF (EMPLOYEE S__FR. G1_EMPL0YEES_DEPARTMENT_C0DE = ") 

THEN 

BEGIN 

ERROR(2); 

CALL__CMD (0) ; 

(This is an undocumented trick. SET_FAILURE() 
does not work here; it lets the query execute.} 

END; 

The final step is to hide the update form for the SECURITY relation under a privileged task, or in a separate 
application. The RALLY documentation explains how to do this. 

The same principle can be extended to protect all data in the database that can be related in a child/parent 
relationship to the SECURITY relation. A further extension would be to give users access to the security relation. 
For example, imagine an application that tracks research and development projects. When a manager adds a new 
project, s/he specifies a project number. At this point, a form/report might be called that allows the manager to 
identify the users who can access information about that project. This form/report would include a List of Values 
showing the usernames in the security relation (reduced to unique values). When the manager selects one of the 
names, RALLY stores a new record for that name and the project ID number. Now the person named by the 
manager has access to the project information. New users of the system must be entered in the security relation by 
a privileged user. 

Thie COBOL code for the external link begins on the next page. 
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IDENTIFICATION DIVISION. 

PROGRAM-ID. RALLY_EXTERNAL. 

AUTHOR. David M. Foster. 

* 

* This program retrieves the USERNAME using the RTL routine 

* LIB$GETJPI (a jacket routine to the $GETJPI system service). 

* Because $GETJPI always returned a 12-byte string padded with 

* blanks, we use the UNSTRING statement to strip the blanks and 

* get the count of meaningful bytes. This is returned to RALLY 

* in the user_name_len variable. 

* 

* To compile and link: 

* 

* $ COBOL RALLY_EXTERNAL 

* $ LINK/SHARE RALLY_EXTERNAL.OBJ, RALLY_EXTERNAL.OPT/OPT 

* 

* The .OPT file looks like this: 

* 

* cluster=foo 

* collect=foo,$code 

* universal=rally_external 

* gsmatch=always,0,6 

* identification^'rally external" 

* 

DATA DIVISION. 


WORKING-STORAGE SECTION. 


01 

dummy_argument 

pic 

s9 (9) 

comp 

value 

0 

01 

ret__status 

pic 

s9 (9) 

comp 

value 

1 

01 

display_return_status 

pic 

ZZZZZ9. 




01 

getjpi_ret_status 

pic 

s9 (9) 

comp 

value 

1 

01 

itemcode 

pic 

s9 (4) 

comp 

value 0. 

01 

jpi$_username 

pic 

s9 (9) 

comp 




value external jpi$_ 

_username. 




01 

process_id 

pic 

9(9) 

comp 

value 0. 

01 

process_name 

pic 

x(12). 




01 

out_value 

pic 

s9 (9) 

comp 

value 

0 

01 

out_string 

pic 

x(12). 




01 

out_len 

pic 

s9 (4) 

comp 

value 

0 

01 

display_out_len 

pic 

ZZZZ9. 




LINKAGE SECTION. 






01 argjblock. 






02 

action 

pic 

s9 (4) 

comp. 



02 

error_code 

pic 

s9 (4) 

comp. 



02 

help_number 

pic 

s9 (4) 

comp. 



02 

failure_flag 

pic 

s9 (4) 

comp. 



02 

param_area 

pic 

x(1016) 





02 ext__link_l_parms redefines param_area. 


03 in value. 
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04 user_name__len pic 9(4) comp. 

04 user__name pic X(12) . 

PROCEDURE DIVISION using arg_block giving ret_status. 

0 . 

evaluate action 
when 1 

move jpi$__username to item_code 
call "libSgetjpi" using 
by reference item_code 
by value 0 
by value 0 
by value 0 

by descriptor out_jstring 
by reference out_len 
giving getjpi_ret_status 
if getjpi_ret_status is failure 
then 

move getjpi_ret_status to display_return_status 
display display_return_status 
exit program 
end-if 

unstring outjstring 
delimited by SPACE 
into user_name 
count in user_name_len 
end-evaluate. 
exit program. 
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submissions 


Articles, copies of viewgraphs, tips and tricks, and graphics 
output are all welcome submissions for the Graphics Applications 
Special Interest Group (GAPSIG) newsletter. There are many ways 
to make submissions: 

1) Send in a tape. Tapes can be 1600 or 6250 BPI 
density. Your editor uses the Mass-11 word 
processing system from Microsystems Engineering 
Corporation, so submissions in this format are okay. 
Otherwise, provide straight ASCII documents. Please 
place any charts into a separate file. And, please 
enclose a letter with your address and any notes and 
description for format that you desire. 

2) Send in paper. Hey, your editor can type and chew 
gum at the same time, so don’t be afraid to send in 
hard-copy. And, if all you have is notes. FINE! 
Send them in!!! We have many folks who can take 
the ideas and flesh them out with English language 
extensions. Questions are desirable, too; DECUS 
should, in the opinion of your humble editor, be a 
place to trade information, so questions count for as 
much as answers here. 

3) Mail to HAYS on DCS. If you have a DCS account 
and the article is all textual, mail it to HAYS on the 
DCS system. 

Your editor’s address appears in the from the editor section, so 
mail yours in today! 


X, version 10 


This editorial is solely the opinion of the author and does not 
necessarily reflect the views of DECUS, Digital Equipment 
Corporation, or KMS Fusion, Inc. 

Bob Hays 
KMS Fusion, Inc. 

3621 South State Rd. 

Ann Arbor, MI 48106 

Well, I'm spoiled and spent for another few months; just got 
back from the Cincinnati Symposium two days ago. While the 
Symposium had its normal selection of no-shows and canceled 
sessions, all in all it appeared everyone enjoyed themselves. 

Those of you reading this are probably used to changes, so this 
issue should sail right along. You’ll notice the new warning (not yet 
certified by the surgeon general) about editorial opinion. This helps 
protect all concerned and notifies you, the reader, that I could be in 
''flame" vs. "analysis and reason" mode (personally, I like the 
warning). 

The newsletter will be in two-up portrait mode from now on, 
based on long discussions with Frank Borger, our valiant Newsletter 
Committee Chairman. Frank deserves all the applause and credit 
available for taking on a job where you try to saddle and watch 
twenty-two or so different editors that may all be at least a little crazy 
(nuts?). Now that I’ve had a chance to meet some of the other 
editors, I’m no longer amazed at how great the newsletters are; these 
editors are a dedicated lot! 

The Spring Symposium also saw the first-ever Newsletter Booth, 
where members came to find out about the SIG Newsletter. This 
method of providing members with information seems successful, and 
I would expect it to continue in Anaheim this fall. 

There are many new issues to consider about the newsletters 
and DECUS in general raised in Cincinnati, but for now I want to 
rest and think about all the events from the last meetings. Therefore, 
this issue displays slides from a talk on the X windows standard 
delivered by Dana Laursen and Bob Toole from Tektronix, Inc. 
Keep your eyes on this space in the future for more information on X 
and DECwindows, not to mention tutorials on GKS and some image 
processing language comparisons. 


Dana Laursen, Tektronix, Inc. 
Bob Toole, Tektronix, Inc. 


X presentations (version 10) 


Dana Laursen 
Bob Toole 
Dana Laursen 


X overview 
X programming 
X toolkit 


Graphics Workstation Division 
Tektronix, Inc. 


Interactive software architecture 


hardware 
operating system 


window system 

programmer J 

user interface tools 



user interface mgm t system 



windowed system utilities 

user 

applications 
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Event types 

mouse button or keyboard key 
mouse motion 
border crossing 
window damage 



Event processing 

queue per process 
preemptive selection 
asynchronous aspects 
simple and complex 



Redisplay on damage events Window hierarchy 

server repaints background event propogation 

client redraws window contents siblings are ordered (clipping) 

parents clip children 



Resources 


Raster graphics 


server and client resources window-relative pixel coordinates 

databases no display lists or transformations 

allocation and activation graphics to display only 

deferred bindings device-dependent representations 
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X capabilities (version 10) 

variety of displays 

device independent applications 

network transparency 

display of multiple applications 

output to partially visible windows 

low-level raster graphics 

L_ programmable window hierarchy 

_ multiple interfaces (policy-free) 


Architecture 

operating system and hardware 
server and clients 

terminal emulator and applications 

window manager 

libraries 

client utilities _ 


X server 

device-independent graphics 
byte stream protocol 
local and remote clients 
requires OS driver, sockets, selectO 


Libraries 


Toolkit user interface 


Xlib 


windows 

events 

graphics 

resources 



X utilities 


window managers 
terminal emulator 
image and printer filters 
bitmap editor 
font displayer 
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Configurability 


X defaults 
window manager 
command line options 
key bindings 
color names | 



User interface 

xterm and uwm 
qualified mouse buttons 
multiple toolkits 
chaotic ergonomic nightmare 



Widgets 

presentation & interaction = policy 
widgets are windows 
simple or composite 
encapsulation 

-fn c=== ^ 

- 1 CZZD 

- 0^0 _ 


Intrinsics 

standard user interface primitives 
interaction within & among widgets 
input and dispatch 
geometry management 
context management 
resource management 
translation management 
error handling 


o_ 
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X capabilities (version 10) 

variety of displays 
device independent applications 
network transparency 
display of multiple applications 
output to partially visible windows 
low-level raster graphics 

—— programmable window hierarchy 

- multiple interfaces (policy-free) 


X version 11 

corrects many deficiencies 
additional functionality 
more complex 

comparable performance at best 
incompatible 

standardization, frozen protocol 
—— user interface toolkit 

- 3-d graphics and other extensions 
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FROM THE 

EDITOR'S KEYBOARD 


The following editorial is solely the 
opinion of the author, and does not represent 
the views of DECUS or of Digital Equipment 
Corp. Responses to the Editor's remarks are 
heartily welcomed. 

After a full week (as in 7 days straight) 
at DECUS, your humble servant would like 
nothing better than to be able to relax for a 
week or two, but as usual, no luck, a deadline 
fast approaches. 

The major event that occurred at spring 
DECUS was that the IAS SIG has merged back 
into RSX, where it was once begat, some 5 
years ago. The impact of continual user 
migration was especially felt at this 
symposium, which happened to be scheduled in 
conflict with the major military users' 
meeting, so that all our military users, and 
Nancyfaye Autenzio, our DEC counterpart, were 
not at Cincinnati. 

Since this is also a small anniversary 
for me, having completed 2 years as your 
editor, it is with very mixed feelings that I 
compile this newsletter. Please excuse me if 
a few emotions leak out into this issue. 


IN THIS ISSUE 


This issue will be devoted to the DeVIAS 
LUG/SIG, its past, present and future. We will 
look back at the history of DeVIAS, we will 
report on the present condition, and look 
forward to the future. 


CONTRIBUTION 

GUIDLINES 


Contributions of articles, SPR's, 
letters, etc. will be accepted in any form, 
(including notes jotted on gravy-stained 
tablecloths.) They will be more happily 
accepted in one of the following formats: 


Paper submissions will always be 
accepted. Publishing may be delayed until the 
editor gets some time at the keyboard to 
convert them to our current format. We can 
accept submissions by FAX. Call for info. 

Contributions may be submitted on tape, 
(800,1600, 3200 or 6250 BPI,) DEC-tape II, and 
DecMate or RTll floppies. We're not fussy, 
we'll even accept paper tape or cards. We can 
read any IAS/RSX, RTll, VMS format. Any media 
sent to us will be promptly returned. 

We have 2400/1200 baud modems on our IAS 
system and our VAX, with KERMIT for electronic 
submission. Give the editor a call @ (312)- 

791-8075 (preferably later in the day,) to 
obtain access info, etc. You can also submit 
over DCS, by sending mail to BORGER. 

If you have a problem you would like to 
submit to the Devias Demon, send it to the 
Editor at the following address. Answers to 
problems from members (or anyone) should also 
be sent to the Editor at: 

Frank R. Borger 
Michael Reese Medical Center 
Department of Radiation Therapy 
Lake Shore Drive at 31st St 
Chicago, IL 60616 


TEN YEARS 
AGO THIS MONTH 


Since the June and July issues of the 
RSX/IAS multi-tasker were combined in 1978, 
and were reported on last issue, no special 
section will appear this issue. Much of this 
issue will be nostalgia anyway. 


RSX AND IAS SIGS 
MERGER NEWS 


At the Spring DECUS, the IAS and RSX SIG 
steering committees voted to merge into the 
RSX/IAS SIG. The proposal was submitted to the 
SIG council, was accepted, and went into 
effect at the close of the Symposia of Friday, 
May 20th, 1988. 
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Members of the IAS SIG steering 
committee met with the RSX steering committee, 
and are fitting in well (often in their 
equivalent positions,) in the combined SIG. 
Although some details and shuffling need to be 
worked out, the merger is going remarkably 
smooth. 

For the present, it has been agreed to 
let the RSX/IAS SIG continue to publish both 
the Multi-Tasker and the DeVIAS letter, 
continuing a tradition that was maintained for 
two years when the DeVIAS letter and the 
Multi-Tasker were "bundled" into one package 
before the combined Newsletters came into 
being. 


WHO'S WHO IN 
THE DEVIAS LUG 
AND THE IAS SIG 


In the following lists, we are attempting 
to list major members of DeVIAS and IAS, both 
past and present. We can't mention all the 
people who contributed their time and energy, 
so if we left someone out, please accept our 
apologies . 


John Jenkinson 

Mostek Corporation 

Fall 1983 thru Spring 4984 

Ron Fussell 
AFIS 

Fall 1984 thru Spring 1984 

Skip Stanfield 
US AF 

Fall 1985 thru Spring 1986 

Mike Robitaille 
Grumman - CTEC, Inc. 

Fall 1986 

Lynda Roenicke 

Naval Ocean Systems Center 

Spring 1987 thru Spring 1988 


LIBRARY COORDINATORS: 

Mike Robitaille 
Grumman - CTEC, Inc. 

August 1983 thru June 1986 

Bob Schultz 
INCO inc. 

July 1986 thru September 1987 


LUG/SIG CHAIRMEN: 

Bob Curley 

University of Pennsylvania 
Inception thru spring 1986 

John Roman 

McDonnell Douglas 

Spring 1986 thru Fall 1986 

Mike Robitaille 
Grumman - CTEC, Inc. 

Fall 1986 thru Fall 1987 


Ted Smith 

University of Pennsylvania 
October 1987 thru ... 


DEC COUNTERPARTS & GURUS: 
(Listed alphabetically) 

William Auperlee 

Nancyfaye Autenzio 

Wayne Blair 


Alan Frisbie 

Flying Disk Systems 

Fall 1987 thru Spring 1988 


NEWSLETTER EDITORS: 

Stephen Keith 

American College of Radiology 
Inception thru June 81 

Bob Curley 

University of Pennsylvania 
July 1981 thru September 1981 

Mark Wiederspahn 
University of Texas 
October 1981 thru May 1982 

John W. Drummond 
Ontario Hydro 

June 1982 thru January 1985 

John Roman 

McDonnell Douglas 

February 1985 thru June 1986 

Frank R. Borger 
July 1986 thru . 


Norm Booth 
John Brady 
Carol Chorlton 
William Ferry 
Mike Garcia 
Cliff Harvey 
Arnold Hay 
Tim Leisman 
Bob Mack 
Alison Nylander 
Mike Reilly 
Ricardo Robles 
Chuck Turley 

OTHER STEERING COMMITTEE MEMBERS 
Kathleen Anderson (Whims) 


SYMPOSIA COORDINATORS: 


Ray French (RSX Liason) 
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George R. Wells (Membership) 
Thomas O'Keefe (CommComm rep) 
Doug Reno (Member at large) 
Kerry Wyckoff (Member at large) 
Ken Guralnik (Whims, etc) 


NEWSLETTER CONTRIBUTORS: 

William F. Cael 
P. L Ev ron 
C. Normal Turrill 
Ed Herold 
System Three Inc. 

Paul Clayton 
Stephen Keith 
Tim Mahaney 
Lawrence DCragg 
Scott Wells 
Bob Stodola 
Darrell Thomas 
Otto Titze 
Frank Anderson 
Ray French 
Mark Wiedershahn 
Frank Borger 
John Hayes 
Gary Cramblitt 
J. G. Kromme 
Alex Yovanovich 
Bob Curley 
Terry Bossert 
Richard Evans 
J. G. Kromme 
Greg Milne 
Jim Field 
Sed Mir 
Art McClinton 
George Wells 
Jeff Goudenough 
Sandy Russell 
Allen Jacowitz 
Joe Volanakis 
Mary Roberson 
John Guidi 
Bob Turkelson 
William Wood 
Dan Stebbins 
J. L. C. Plasman 
Jim Underwood 
Anne K. Foley 
Michael Scott Ward 
Bob Short 
John Roman 
Mike Robitaille 
Allison Nylander 
Mike Reilly 
Arnold Hay 
Carol Chorlton 
Mike Garcia 
Bob Molie 
Terry Medlin 
Ed Herold 
Jim McGlinchy 
Ellen Buffington 
Ron Fussell 
Klaus Centmayer 
Dave Brown 
Jim Williams 
Jeff Mackenzie 
Otto Lowas 
Robert A. Ehle 
Rebecca Marks 
Wayne A. Blair 


Erik Von Der Blauen 
Linda Roenicke 
Mike Robitaille 
Steve LeFevre 
Anon 


THE LORE OF IAS 


In putting together this issue, it was 
hard to decide just what should go into it. 
There were several short submissions, such as 
Bob Curleys famous equation 

2(NaCl aq) 


(C-C-C-C-C-C-C) 

What is that, why its Saline, Saline, 
over the Seven C's. (Bob warned readers that 
he would keep up that stuff until readers 
submitted to the newsletter. It worked!) 

Also included is our page of IAS buttons 
and badges. I remember the furor when Stephen 
Keith brought the orange DeVIAS ribbons to a 
symposia, and DECUS said they weren't standard 
DECUS ribbons. Later Jim Hopp brought the 
famous BLACK IAS ribbons, to advertise the 
demise of IAS. Fortunately, IAS is still with 
us . 

One of the most notable entries in the 
life of the SIG was the introduction of the 
"Sports Pagp" and the "Society Page" to the 
newsletter. Copies of these are included. 

Another memorable issue contained the 
Dear IAS Enthusiast letter reporting on the 
marriage of Mike and Alison. It to is included 
here. 

Of course, there is much more that should 
have been included, but couldn't be, due to 
space limitations. I hope this retrospective 
brings joy to all. 


THE PROGRAM OF 
THE MONTH CLUB 


For this issue, we have included the 
famous "The Forty Seven Test" 


FIND THE HIDDEN 
FEATURE CONTEST 


And, to close out this issue, 
system has undocumented features, but 
actually had a contest to find 3 
undocumented features. Unfortunately, 
were so well hidden, that no-one ever 
them. 


every 
IAS 
new, 
they 
found 
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SHARING 









The Sports Page 


The First Great Interinstitutional MTREK Challenge Dinner was 
held at The Institute for Cancer Research at 19J00 on September 
3* 1981* The challengers* representing Republic Management 
Systems* were the infamous Paul Clayton and his cronies* Bob 
Falcione and Rich Kolbe. The home team was represented by Bill 
Cael* Bob Rudkin* Bob Stodola* and Bill Uood* playing three 
ships in rotation. 

The MTREK Challenge Dinner* played at highly irregular 
intervals* consists of two grueling hours of heated battle. The 
winners are then dined amid elegant surroundings* during which 
the match and other subjects of common interest are discussed* 
all at the expense of the losers. (The winners are privileged 
to make the official report of the results.) 

The first hour* played under the ICR standard MTREK rules in 
universe number 645* resulted in the following scores! 


Institution 

Ship number 

Score 

Total 

RMS 

i 

-9067 


RMS 

n 

-8077 


RMS 

RMS 

3 

12695 

-4449 

ICR 

6 

34578 


ICR 

7 

54493 


ICR 

ICR 

8 

38552 

***** 


The 

second hour» 

played with RMS's hotly debated 

-- 

with which 

the ICR team 

had no experience 

number 311» Save 

somewhat more 

balanced resultsi 

Institution 

Ship number 

Score Total 

RMS 


1 

18555 

RMS 


2 

4223 

RMS 


3 

12376 

RMS 



35154 

ICR 


6 

9491 

ICR 


7 

19506 

ICR 


8 

43187 

ICR 



72184 


modifications 
- in universe 


Afterwards* the ICR team was treated to a delightful meal at The 
Toll House Inn of Huntingdon Valley. The challengers* humbled 
by the devastating strategies of the ICR team* desired a rematch 
on the home field after a suitable period of practice. 
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SOCIETY PAGE 










The guest of honor was an 11/84 
running IAS Release 3.2 B (left) 
The 11/84 was resplendent with 
RC25, TU80, and matching VT240's 



Two IAS wizards present were Frank Borger (left) 
and Bob Schuldt. 
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Division of Medical Physics 
Department of Radiation Therapy 
University of Pennsylvania 
P.0. Box 7806 

Philadelphia, Pennsylvania 19101 
23 August 1987 


Dear IAS Enthusiast, 

It has been a long time since I last contributed to the 
DeVIAS Letter. An important event has caused me to break my 
silence. Since there is no official "Society Page" in our news¬ 
letter (There was one occurrence of the "Sports Page" reporting 
a massive M-Trek game!) this mechanism must suffice. 

WEDDING IN MASSACHUSETTS 

Our friends Alison Nylander and Michael Reilly were married 8 
August 1987 in Massachusetts in a clearing in back of the 
couples' new house, encircled by woods. Michael and Alison 
were, for those of you new to the IAS world, important software 
engineers in IAS Development for a long time - from the time 
when IAS Development was moved from Reading, England to Massa¬ 
chusetts until about a year ago. They have contributed hugely 
to IAS, but much of that is obscured by the "namelessness" of 
operating systems - especially when you don't have the sources! 
They have contributed mightily to DECUS, and the IAS SIG in 
particular, through uncounted symposia sessions explaining the 
technical aspects of IAS and Pre-Symposia Seminars when the IAS 
SIG starting back when the SIG "really needed the money". Most 
recently, they presented a seminar on C in Nashville. 

I confess a lack of ability to describe, as is usual in this 
circumstance, the gowns of the bride and bride's maids. I 
can say that Alison was beautiful in a long white gown, but 
that doesn't do her justice. I can also say that there was 
some comment about Michael Reilly and Bob Curley both in 
tuxedos! No blue jeans evident. 

There were important visitors, from an IAS point of view: Bob 
Mack, Bill Aupperlee, Wayne Blair and Richardo Robles. They are 
all still involved with IAS. Yes, there was some shop talk, 
but not much. 

I am sure that I spoke for all of us in the IAS SIG when I 
wished them well. The ceremony was simple and beautifully 
done, causing me to remember when Barbara and I took our vows 
"long ago". There was leaning white birch tree forcing the 
recollection of Robert Frost's poem. I tend to get maudlin 
when I return to New England, especially when invited to share 
such a profound occasion. 
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The Fourty Seven Test 

This program performs a (perhaps infinite) test of memory. Although written in 
MACRO assembler (or just straight binary) it also manages to satisfy most of the 
stringent and rigorous criteria developed by the proponents of strictured pro¬ 
gramming* This is because the p rogram consists (initially and at any point dur¬ 
ing Its (perhaps infinite) execution, of a single instruction. 

Further, the program is fully portable between all POP-tl's (and perhaps the VAX 
In compatibility mode). Apart from testing memory it also tests the program 
counter to the limit (literally) by running it backwards (Thus, it « not only 
written Top Down but also executes Top Down). The progr am does not require an 
operating system of any kind (and will quickly do away with any such if properly 
run.) The pro g r am is completely position independent. 

TERMINOLOGY - The algorithm describing the Fourty Seven Test will be described 
in a new conceptual pro gr a mmi ng language called Ida (named after Charles Bab¬ 
bages dog). Ida is very much like *Programmers Vernacular* - that is - poorly 
spelled English with a lot of gestures, aah*s and urn's. 

PHILOSOPHY - Before beginning with the introduction to the Forty Seven Test I 
would like to present a bit of background behind its philosophy - but space does 
not permit. Since The Fourty Seven Test does not involve any data the discussion 
of Data Types can be elided. In a like vein, the 47 test does not involve any 
arithmetic or (explicit) transfer instructions. Therefore, Ida not only forbids 
the use of the GOTO instruction, it also disallows the CALL. In fact Ida only 
permits a single command: the Fourty Seven command (See footnote 4.7 of section 
4.I.7.3.3.5.) 

THE PROGRAM - A last minute hitch in ironing out some ambiguities in Ida forces 
us to revert to MACRO in presenting this p ro gr am - but, as will be shown in the 
forthcoming seven volume Rationale, it is possible, using a context frozen gram¬ 
mar, to proove a unique one-to-one mapping between MACRO and Ida. 

.title the fourty seven test 
.enabl k 

ASSEMBLY INSTRUCTIONS : 

!«ecuteaist/crossreferb*:e FOURTY 

;DATA DEFINITION 

;The Fourty Seven test requires only one piece of DATA, and that is 
;the START_ADCRE5S. This is defined in the following definition and 
;ls the default setting for a 28k (word) machine. 

STARTADORESS=160000-2 ,Change this to your liking 

;The comment line below (,—) must begin with a semicolon. Otherwise 
;MACR0 will interpret it as a sequence of 66. unary minus signs. 

;Since MACRO pushs a couple of words on the stack per unary operator, 
pt very quickly runs out of stack space and crashs. 


MAIN PROGRAM 


PROGRAM ENTRY PO*fT 

;The program is automatically started here by the concluding .END START 
;sequence. RT-11 arrives here with the registers in a mess and no idea 
;about what we're about to do. 


IAS-9 





,-1000*STARTADORESS 


;define the start address 


•code SECTION 
# 

;The Code foe the Fourty Seven Test is impure and should not be run in 
^-read-only memory (ROM, PROM or EPROM), Further, its use on machines 
,*with separate instruction and Data spaces is unpredictable. To ehance 
portability prospects with future PDP-11 Assembler's we have chosen not 
;to use mnemonics (since the information in the MACRO manual is all 
subject to change without notice), but rather, to return to direct 
petal-coded binary. Here follows the Fourty Seven Instruction : 

.word 014747 ;The Fourty Seven Instruction 

^ROCRAM CONCLUSION 

;The rest of program has been left to your imagination - firstly, since 
;it would take up valuable space in the Mf^fl-tasker, and secontfy since 
;this progr a m hasn't got a chance of running under RT-11 anyway. 

•end st art address 

As the concluding comment in the program points out, this program wont run. RT- 
Tl produces a *Not enough memory' message after an attempt to run this 112 block 
progr a m. Therefore, we will have to dump Ida and do the job by hand. Thus: 

(1) Stop the computer 

(2) Load the number 014747 in the highest memory address 

(3) Start the computer at the same address as above 

This can be accomplished on an 28k LSMI with : 

«bieak» 

0157776/ xxxxxx 014747 CretumJ 
6I57776G 

THE OUTCOME - The question is what will happen? Make a guess now. If you're a 
novice - then Just try to guess what memory will look like after the test. If 
you know that, try to work out the terminating conditions of the program. Then 
come back to the next paragraph. 

THE FOURTY SEVEN TEST consists of the instruction 'MOV -<PC),-(PQ'. This 
instruction effectively replicates itself in memory backwards. Thus it fills 
memory with the pattern 014747. It terminates by trapping when it goes below 
location zet o. What happens then depends on the PDP-11 model involved. (Most LSI 
processors end up with alternating halts at 000000 and 177777 (which doesn't 
really exist). This instruction drives a PDP-11 backwards! But it also accom- 
plishs a basic memory test. 

THE FUTURE - I will consider submitting the 47 test (and Ida) to the DECU5 
library after it has been fully field tested (this usually takes, around five 
years). If enough user support emerges it may be worthwhile starting a 47-SIG. 
If you want a copy of the Fourty Seven Test then send a stamped addressed R102 
Disk to the following address: 

Ian Hammond - HAM MONO-soft ware - Am Felborn 22 - D-34 Goettingen - West Germany. 
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ANNOUNCING 


FIND THE HIDDEN FEATURE CONTEST 


The IAS Development Team has included certain undocumented fea¬ 
tures in Update B. These are currently for internal Digital use 
and may be supported in future updates. Three features have been 
identified by the IAS Development Team. This is your chance to 
show what you know about the system. Find the hidden features 
and win a prize. 


Rules 

1. To redeem your prize you must indicate: 

o what the feature is, 
o what it does, 
o where it is, 
o and how to use it. 

2. Judges are the Digital IAS Developers and their decision is 
final. 

3. You must describe one of the three known features. 

4. No Digital employees or their families may enter. 

5. The entries must be received by the DeVIAS Letter Editor by 
December 1, 1985. 

6. Winners will be announced and awards presented at the Fall, 
1985 DECUS Symposium at Anaheim. 

7. The awards have not been determined at press time. However, 
they will undoubtedly be truly outstanding. 

8. Void where prohibited, regulated, or taxed. 

So hurry now! Send all entries to: 

John Roman 

McDonnell Douglas Corporation 
Department N436 
600 McDonnell Blvd. 

Hazelwood, Missouri 63042 
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GLOBAL ACCESS 



MMP 




GLOBAL 


ACCESS 


Volume 2, No. 1 


July, 1988 


MONPS leans you never have to say you're sorting. 


$VIEW(Editor) 

1 have Just returned from a week of sun and fun in beautiful 
downtown Cincinnati, and so, it's time for Your Editor's Biggest 
Winners and Losers from the Spring Symposium. First the jeers: 

Biggest Loser --The food service Gestapo who fanatically filled up 
all the tables (when there was plenty of extra room) and who 
dictated precisely where each attendee should sit. Mother 
please, I’d rather do it myself. 

Also Ran --The four block walking distance to SIG suites in the 
Omni and Westin hotels. Quite a commute to go unwind after 
sessions. 

Now the cheers: 

Honorable Mention --Cincinnati itself. It's as close to the 
Northeast as any Symposium is going to get until Boston in the 
mid 90's, and the Convention Center fit the Symposium just about 
perfectly. 

First Prize --Mitch Brown, the On-Site Scheduler. I schedule a 
pair of Birds-of-a-Feather sessions at every Symposium, and this 
time Mitch and I did it face to face while looking at his room 
availability worksheet. That sure beats shuffling forms back and 
forth; we really must make it a permanent fixture. 
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KERMIT-M is the MUMPS implementation of the popular Kermit 
file transfer program. Just about every computer you could name, 
from CP/M and MS-DOS machines to VAXes and some mainframes, has a 
Kermit. 

The MUMPS Kermit was developed by David Rossiter at the New 
York State College of Veterinary Medicine in Intersystems M/ll 
MUMPS. I received Kermit-M from Columbia University, which is 
the clearing house for Kermit. I made the modifications to get 
it running under Digital DSM-11 and Micronetics MSM-PC. I have 
recently received the latest release from NYSCVM, and I will be 
creating a truly system independent version, which will include 
my enhancements. 

I have found Kermit-M to be an extremely useful tool for 
maintaining multiple sites. We distribute patches to 25 sites 
via modem. This version of Kermit-M will talk to every other 
version of Kermit, and it supports server mode operations. 

Kermit-M will be available through the standard channels and 
will be in the DECUS Library this summer. I don't think it will 
make the catalogue deadline, but if you call, you can order it 
sometime in July or August. 

--Contributed by Michael McIntyre 

[Mike is the MUMPS Sig Library Representative. He expects to 
present a session on MUMPS programs in the DECUS Library during 
the Fall Symposium, and he actively solicits your submissions. 
You can contact him at the address shown in the SIC pages, at the 
back of every issue.--Ed.] 


SHOROLQG 


July 22 
October 17-21 
February ?13-17? 
May 8-12 


Submission deadline for September newsletter 
Fall '88 Symposium; Anaheim, CA 
Canadian '89 Symposium; Vancouver, BC 
Spring ‘89 Symposium; Atlanta, GA 
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BORDER(“Mission") 


A common document around DECUS committees is a "Statement of 
Mission and Goals;" a formal description of where you are going 
and what you must to do along the way. Use of mission in this 
context has always annoyed me. First off, mission has a set of 
historical connotations ("Your mission, Jim, should you choose to 
accept it...") that are simultaneously militaristic and frivo¬ 
lous. Second, and more important, mission comes from the Latin 
word mittere, which means to send, and carries the concept of 
"sent by higher authority." In DECUS, the reality of the situa¬ 
tion is precisely the opposite: SMGs are used to convey informa¬ 
tion (usually, how a given unit intends to serve its constitu¬ 
ency) up, rather than commands down. Accordingly, I set out to 
find a better word. The first that came to mind was mandate. 
Unfortunately, that still carries too much "higher authority." 
Serious research turned up many others, including charge, office, 
duty, and even task. (I don't even want think about the ramifi¬ 
cations of that one!) However, none of them really hit the mark. 
So, I guess I will just have to admit failure on this one, and 
mission will get to stay where it is, right next to goals. 


SNEXT 

As election time draws near, the September issue will con¬ 
tain coverage of how MUMPS will be used during the 1988 Democra¬ 
tic National Convention. 

$NEXT(BORDER )="Speak to" 


^RANDOM 


"Money isn't everything; it can't buy poverty." 

Lewis 


--Joe E. 
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FROM THE EDITOR’S HAMMOCK 


Another symposium has come and gone... 

And I'm still digesting material gethered from Anaheim! 

It seems the more I read, the more I realize I don't know! 

This month I've found a good article to curl up in the 
hammock with. Splash some iced tea on a glass full of 
ice cubes, turn the sprinkler on low, and relax. 

Here is a clear and informative description how one 
group at Westinghouse networked their Workstations. 

The paper was presented at Fall, 1987 Symposium in 
Anaheim, California, and published in the Proceedings. 

I nxe tne pictures. 

Enjoyj 


Judi Mandl 

University o£ Ct. Health Center 
Financial Management Into Systems 
263 Farmington Ave. 

Farmington, Ct. 0b032 
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Basic Networking for Office Automation 


Robert Gary Mauler 
and 

Valerie Cabral Mauler 

Westinghouse Electric Corporation 
Baltimore, Maryland 


ABSTRACT 

This paper will take the mystery out of networking Workstations for non 
technical people. Based on experience gained in networking over 250 PC and 
VAX Workstations, guidelines and recommendations will be made to help 
simplify the planning, Installation, and check out of an Ethernet LAN. The goal of 
this paper Is to help the poor soul who is told to "...automate our office and 
network our PC’s while you are at it." 


After working with Ethernet since about 
1982, and attending a lot of DECUS 
Networking sessions, we are surprised to find 
that there are still a lot of people out there that 
either don’t understand or feel comfortable 
when designing or working with a network 
system based on Ethernet. The goal of this 
paper is to help the not so technical person 
become more familiar with Ethernet wiring 
systems, thus realizing that there is no magic 
going on. If you know and follow a few basic 
rules you too can successfully network your 
office. 

Networking an office should be 
approached in an organized manner. 
Hopefully the network you install will be around 
for a long time, and so it is important to build a 
solid foundation upon which you can add. The 
first thing that needs to be done is what you 
are doing right now, that is learning about the 
topic and planning your network. Secondly, 
you must either install the network hardware 
yourself or at least supervise the installation to 
make sure it is installed per your design (you 
don't need surprises later on when you find out 
that an installer took a short cut). Thirdly, after 
installation of the networking hardware, the 
cabling and other active devices must be 
checked out to verify proper operation. And 
finally, you need to implement a network 
management system both to provide 
diagnostics capability as well as to provide 
statistics for planning future growth of the 
network. 


This paper will deal exclusively with the 
subject of office networking using Ethernet. 
That is, we will discuss how to install a network 
in an office environment using Ethernet 
protocol and RG-58 50 ohm cable between the 
desktop workstation and the wiring closet. 
One of the first confusing things that you may 
encounter is the many terms used by vendors 
to say what we just said. You will hear terms 
such as ThinWire, ThinEthernet, Cheapernet, 
and even 10BASE2 used to describe Ethernet 
using RG-58 cable. In order to be consistent in 
this paper we will use the term ’’ThinWire”, 
which is Digital’s terminology. Another way of 
looking at ThinWire is to compare it to "Thick 
Ethernet" or the standard Ethernet RG-225 
trunk cable. The main difference is that 
ThinWire is smaller in diameter, much easier to 
pull, and cheaper (Cheapernet). The size is 
the major factor that makes it practical to wire 
Ethernet right to the workstation on the office 
worker’s desk. The other major difference 
between the two cabling schemes is the 
difference in cable connectors. ThinWire uses 
what is called a "BNC" type connector while 
the RG-225 cable uses an "N" style connector. 
BNC connectors are pictured in Figure 1. The 
BNC connector is what you might call a "twist 
& lock" since the connector is pushed on and 
then rotated 90 degrees to make the 
connection. On the other hand the "N" style of 
connector is threaded on. When it is 
necessary to connect a computer to the 
network there is a difference again based on 
the type of connectors. Typically 
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when using the RG-225 cable a piercing type 
of tap is made on the cable and then a device 
called a transceiver is clamped onto the cable. 
In the case of ThinWire, BNC type connectors 
are used. A BNC "T" connector allows two 
segments to be connected together and also 
provides a male connector to connect to the 
workstation’s onboard transceiver. 

Once you understand the terminology, it 
time to start learning the rules of networking. 
One source of these rules is a document from 
Digital Equipment Corp. entitled "Networks and 
Communications Buyer's Guide". Although it is 
an excellent source of information be aware 
that it only represents networking products 
from Digital. The same will be true of almost 
any document that you receive from a vendor. 
You need to shop around to get the big picture; 
there’s more than one way to network a 
building. 

When it comes to office networking there 
are only a few rules that you need to 
remember. First, the total length of a ThinWire 
segment is 185 meters or 606 feet maximum 
per segment. Although that may not seem like 
a whole lot, in actual practice it is more than 
enough. The second rule is that there can be 
no more that 30 nodes or devices maximum 
per segment. The 30 node rule also implies 
that there should be a maximum of 60 


connectors per segment (30 nodes X 2 
connectors per node). Here again, with the 
use of multi-port repeaters, as you will see 
later on, your network will probably never 
reach the maximum of 30 nodes on a segment. 
Third, ThinWire segments are to be connected 
together with BNC "T" connectors which are 
then directly attached to the workstation. In 
other words there should NOT be a length of 
cable between the workstation and the BNC 
"T" connector. In addition, if a workstation is 
removed permanently then it is preferable to 
replace the BNC "T" connector with a BNC 
barrel connector. The fourth rule is that both 
ends of an Ethernet segment of wire must be 
terminated with a 50 ohm terminator. In 
addition, one end and only one end should be 
grounded. All other connectors along the 
segment should be isolated from ground by 
using the plastic shields provided with your 
network interface card. In the case where you 
are using a multi-port repeater from Digital 
Equipment Corporation (DEMPR), then the 
requirements for 50 ohm termination and a 
ground on one end of the segment are 
provided for by the DEMPR. One last note 
before we leave these rules is that Ethernet is 
a multi-drop configuration and not a ring type 
wiring scheme. Therefore you must insure that 
you don't form a ring when wiring with 
ThinWire. 


185 meters (606 feet) MAXIMUM 



Figure 1 
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NODE A 


NODE B 


Figure 2 


To form the simplest network it is going to 
take two nodes. There could be a few 
deviations such as one node being a terminal 
server and one node a VAX, but for this 
discussion we will assume that both are 
MicroVAX systems (see Figure 2). In the case 
of a MicroVAX, and for that matter most 
minicomputers, you will find on the back of the 
cabinet a 15 pin miniature D connector (looks 
like a small RS-232 connector) labeled 
Ethernet. The first item that you will need is a 
transceiver cable. The purpose of the 
transceiver cable is to provide DC power and 
digital data signals to a Ethernet transceiver. 
Here is where the real fun starts. The 
"transceiver" has had many flavors over the 
years. Back in the beginning it was just called 
a transceiver, but then DEC, Intel, and XEROX 
got together and came out with Ethernet 
Version 2. So then you had two types of 
transceivers, a Version 1 and a Version 2. To 
further complicate matters, another group of 
engineers got together and now we have an 
802.3 standard. The main difference between 
these three types of transceivers is the 
"heartbeat test" or SQE (Signal Quality Error 
signal). Version 1 and 802.3 transceivers do 
not use the SQE signal while the Version 2 
transceiver does. It is important to use the 
correct type of transceiver for a particular 
Ethernet device or controller. In some cases 
when you connect the wrong transceiver it just 
won't work. But things can really get bad if you 


connect a transceiver with heartbeat to a 
controller that is not expecting the heartbeat 
and mistakes it for a real packet collision. In 
this case the device will sort of work but you 
will wonder why the network is so slow. 

One area of confusion that we have 
noticed is in how to mix Thick and Thin types 
of transceivers on a network. In Figure 2 there 
are two types of transceivers shown. The 
transceiver on the left represents a Thick 
transceiver that has an "adapter" to make it 
compatible with ThinWire wiring. There are 
several ways to make this transition. One very 
expensive scheme used by DEC is to employ 
what they refer to as a "Loop Back 
Transceiver". This method requires that the 
Loop Back Transceiver be modified by 
removing it's 50 ohm terminators and replacing 
them with "N" barrel and ”N to BNC female" 
adapters. For those who are budget conscious 
there is another approach. AMP Corporation, 
the makers of most of the media attachment 
devices for DEC and other Ethernet vendors, 
offers an adapter that simply replaces the 
Thick cable clamp/tap assembly with a new 
assembly that provides a BNC "T" connector 
for ThinWire cabling. A big advantage to the 
AMP method is that the number of connectors 
in the cable path is reduced by four. Not only 
is this an obvious cost savings but there are 
less electrical RF joints to attenuate the signal 
and otherwise cause trouble. 
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The Transceiver on the right in Figure 2 is 
an example of a ThinWire Transceiver. A 
ThinWire Transceiver is one that is designed 
and built to connect directly to ThinWire 
cabling without the need for any adapter. If the 
network you are installing is in an office 
environment then you should take advantage 
of these smaller and lower cost devices. 


As people see the advantages of 
networked workstations, the network will 
quickly grow beyond a single work group. A 
device called a Multi-Port Repeater is used to 
connect a building Ethernet Trunk cable to the 
ThinWire segments running to desks (see 


BNC *T' CONNECTOR / ADAPTOR 



NODE B 


Figure 3 


The network that is shown in Figure 3 
takes our basic network one step further. We 
have now added two workstations. It is 
apparent from the illustration that there are no 
transceivers associated with the Workstations. 
But there must be transceivers, since any 
Ethernet connection is through a transceiver. 
In this case the workstation has its transceiver 
electronics built onto the Ethernet controller 
board or in some cases the CPU, memory, I/O, 
and network controller are all on one large 
motherboard. The workstation will have a BNC 
female connector protruding from the rear of 
the cabinet to which a BNC "T" connector is 
attached. If the Workstation is physically the 
last node on a segment then one port of the 
"T" connector is terminated with a 50 ohm 
terminator. Otherwise the "T" connector is 
placed in a "series" fashion. 


Figure 4). Digital Equipment Corporation calls 
their device a DEM PR which stands for Digital 
Ethernet Multiple Port Repeater. This type of 
device is available from other vendors besides 
DEC, but for simplicity I will use the term 
DEMPR in this paper. The DEMPR should be 
placed in a wiring closet located such that the 
farthest workstation is within a 600 foot radius 
of it. A DEMPR has 8 BNC female connectors 
to which 8 ThinWire segments can be 
attached. If a port is not connected to an 
active segment then a 50 ohm terminator 
should be installed. An 802.3 type transceiver 
(non heartbeat) and cable is used to connect a 
DEMPR to the Ethernet Trunk cable. The 
transceiver used for this application would be 
the piercing type. A maximum configuration for 
a DEMPR will allow up to 232 nodes in a 600 
foot radius to be connected. 


NTW-5 





MultiPort ThinWire Ethernet Repeater 


50 n TERMINATION ON UNUSED PORTS 



> SEGMENT LED ^SELF TEST PUSHBUTTON 
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TERMINATOR 
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TRANSCEIVER CABLE 


ThinWir® 

Transceiver 


Figure 4 


Built-in ThinWire Transceiver 


The DEM PR can also be used in a "local" 
configuration which means that it is not 
connected to an Ethernet Trunk cable. This 
type of configuration is useful in small 
buildings. For example, in a small three story 
building the wiring closet could be placed 
centrally on the second floor. From the second 
floor wiring closet ThinWire segments would be 


pulled to all three floors. If one DEMPR is not 
enough, up to eight can be connected using 
DEC'S DELNI (Digital Ethernet Local Network 
Interconnect) or a similar type device. An 
example of this type of configuration is shown 
in Figure 5. With this type of configuration it is 
possible to connect up to 1,856 nodes. 


ETHERNET LOCAL NETWORK INTERCONNECT 



TRANSCEIVER CABLES 
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MultiPort ThinWire Ethernet Repeater 



Up to now we have been talking about 
workstations that are connected in a serial 
fashion. Recently there have been 
announcements by DEC, 3COM, and 
SynOptics in the area of twisted pair wiring 
plans for Ethernet. The motivation for this is 
based on the fact that most buildings already 
have telephones installed that use twisted 
pairs. Therefore, there are usually twisted 
pairs already available at a site. In addition, 
the twisted pair technology is mature and well 
understood by installers and maintenance 
personnel. An advantage of the twisted pair 
wiring scheme is that it is a point-to-point 
connection. That is, the workstation is 
connected directly to the network through a 
repeater. This type of wiring makes it very 
easy to troubleshoot problems because there 
are only three pieces to worry about: the 
workstation, the copper wire, and the network 
repeater. In Figure 6, we show how a point-to- 
point configuration can be connected using 
ThinWire as the media. The picture would look 
almost the same if you were to use twisted pair 
media except that it would be necessary to add 
two adapters to convert from ThinWire to 
Twisted Pair and back again. These adapters 
would be placed between the workstation and 
the DEMPR. 

As usual there are trade-offs to be made 
when deciding between serial and point-to- 


point wiring plans. But it usually comes down 
to what your organization is willing to pay for. 
It should be easy to see that in the point-to- 
point wiring scheme, the cost of the DEMPR 
and its transceiver is only divided between 8 
workstations. Whereas for the serial wiring 
plan the cost of the DEMPR, etc. can be 
divided among as many as 232 Workstations. 

Now it is time to look at a practical 
application for all of the Ethernet devices we 
have been talking about so far. Figure 7 
shows the layout of a typical office that you 
might be required to network. This example 
will allow us to explore ideas for placing 
computer equipment around the office, as well 
as several of the wiring schemes that are 
possible. Starting at the lower left corner of the 
floor plan you see a computer room. Although 
it is not necessary to have a computer room for 
a small MicroVAX, it does provide a central 
location not only for the computer but also for 
the user manuals, software distribution media, 
and storage of backup tapes. Another 
advantage is that the Server is out of high 
traffic areas where people might have a 
tendency to "push buttons". The next area 
along the bottom is a cubicle set aside for 
shared printers. This is definitely a necessity 
since printers require supplies of paper 
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as well as a table to hold print-outs waiting to 
be picked up. If your printers are within 
approximately 100 feet of the Server, then they 
can be hooked up using standard RS-232 
wiring. If the distance is much farther or the 
VAX server does not have RS-232 ports then 
an Ethernet Terminal Server such as the 
DECserver-200 will be required to make the 
connection. 


there are no workstations currently installed 
but a drop is installed for future growth. From 
there segment B is routed through the ceilings 
and down the walls of the offices along the top 
of the floor plan. In each office the ThinWire 
cable exits the wall through a face plate and 
attaches to a BNC "T" connector on the 
workstation. From there it continues on to the 
next office. 



The next area that is shown is a wiring 
closet. We feel that all communications wiring 
should be pulled back to a wiring closet. The 
wiring closet should be large enough to handle 
both data and voice patch panels as well as 
data networking equipment such as modems, 
repeaters, bridges, and terminal servers. In 
addition the closet should be well ventilated 
and have independent power outlets. The 
wiring closet becomes even more important 
when you want to share twisted pairs with the 
telephone people so that you can run Ethernet 
over their unused pairs. 

All ThinWire segments originate from the 
wiring closet. The first segment in our example 
is labeled A. This is wired as a point-to-point 
segment since it was convenient and there 
were no other nodes close by. Segment B 
starts out by going to a conference room where 


The middle of the floor plan contains 
desks divided into cubicles using free standing 
partitions. In most cases the ThinWire is 
dropped down from the ceiling through some 
type of conduit to floor level. Then if you are 
lucky you will be able to route the ThinWire 
through data wiring troughs built into the 
cubicle partitions. If your partitions do not have 
a built in wire trough then you will have to 
improvise another way to keep the data cable 
off of the floor so that it will not be eaten by the 
cleaning crew's vacuum cleaners or floor 
polishers. As before, the workstations are 
connected in a serial fashion using BNC "T" 
connectors. 

In this example, you will notice that the 
segments on the average have about 8 
workstations in series. In addition, the typical 
total segment length is about 300 feet. In both 
cases we are not anywhere near the design 
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limits for ThinWire. By using DEMPR’s to limit 
the number of workstations in series, it is 
possible to have multiple segments that are 
electrically isolated from one another. That is, 
if one of the office ThinWire segments gets cut 
by a vacuum cleaner, at worst it will only take 
out 5 to 10 workstations. It is true that it will 
take a little longer to isolate the problem since 
there are 10 to 20 pieces of coax per segment 
to check, but the coax is readily accessible in 
the wiring trough in the office partitions. Based 
on our experience over the past five years the 
failure rate is very low and once a problem is 
reported the failing part can usually be located 
within 15 minutes. By including short serial 
segments in an overall point-to-point scheme 
we have found the best compromise between 
the economy of serial wiring and the 
convenience of point-to-point. 


obstacles such as fire walls, air conditioner 
ducts, etc. At the conclusion of the installation 
the design drawing and the as built drawing 
should be compared so that an accurate 
record is produced and filed for future 
reference. We would also suggest that a form 
such as the one in Figure 8 be used to build a 
data base on each segment that is installed. 
The information on this form will be invaluable 
to the person who may one day want to 
expand the network or who just wants to locate 
a problem with one of the workstations. As 
your network grows to the point where you 
want to use network management tools such 
as a LAN Analyzer or DEC’S EtherNIM, then 
this table will allow you to easily find and 
identify nodes on the Ethernet cable. 


Wiring Closet Location_ Sheet_of 

Multi-Port Repeater ID_ Date_ 



Keeping good records of the physical 
layout of your network cannot be over 
emphasized. There are three phases to this 
process. First, as you do your network design, 
estimates of cable lengths and placements 
must be made and recorded on the wiring plan 
drawing. Then as the cable is pulled the 
installer should record any modifications that 
have to be made because of unexpected 


This brings us to the subject of network 
trouble shooting. What if it doesn't work? We 
believe that the best approach is to be positive, 
assume that it will work, and try to load your 
networking software. Nine times out of ten 
everything will be fine. But if the network does 
not come up, pay attention to any error 
messages you get on your terminal for 
possible software configuration errors. 
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Although programmers may wish to disagree, 
we have found that it is usually a software 
problem. If you happen to experience one of 
the rare occasions where the hardware does 
fail then it is time to take a look at the 
hardware. Fortunately, the engineers that 
designed a lot of the networking hardware on 
the market were very generous with LED's. 
Just about every active network device that I 
have used has had it share of status indicators. 
We recommend reading the instruction manual 
that comes with your particular set of 
equipment to see just what kind of information 
can be determined by observing the LED’s. 


These simple techniques to trouble shooting 
will resolve most hard failures. If you are 
experiencing intermittent or network 
performance types of problems, then you will 
probably need to use a device called a LAN 
Network Protocol Analyzer. For example, if it 
takes a lot longer to transfer files than you 
think it should at lOMB/sec then a LAN 
Analyzer can help by showing you statistics on 
network traffic. For example a good analyzer 
will allow you to determine the number of 
collisions per second, lost packets, jabber 
nodes, average packet sizes, etc. 



NODE 2 


Figure 9 


The "process of elimination" is a 
technique that will work in cases where there is 
a hard failure. By this we mean that nothing is 
going across the segment and a SEGMENT 
LED status indicator is probably lit on a 
DEMPR. Refer to Figure 9 to follow along with 
this process. The first step is to disconnect 
segment B from NODE 1 and replace it with a 
50 ohm terminator. Then reset the SEGMENT 
LED by depressing the SELF TEST 
PUSHBUTTON and then letting it go. If the 
SEGMENT LED is on then segment A must be 
the problem. On the other hand if the 
SEGMENT LED remains off then that segment 
is working and you did not locate the problem. 
Then you must reconnect segment B and 
repeat this procedure on Node B and so on 
down the line until you locate the problem. 


Although it is difficult if not impossible to 
record on paper everything that we have 
learned about networking in the last five years, 
we hope that by pointing out a few areas 
where there is potential for confusion, 
newcomers to networking will feel comfortable 
with Ethernet wiring in an office environment. 
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FROM THE EDITOR... 


I was in the enviable position this month of having so many great articles to choose from, it was hard to 
decide what to publish first! Thanks to all of you who have contributed... keep up the good work! 

I settled on another great technical article from Trace Roth on how to modify two Time Management 
calendars. And We have something a little different than our standard informational article, a request for 
information from you, our readers. We also had just enough time to squeeze in one or two informational 
items about the Cincinnati Symposium: One on the upcoming SIR listing and the other a note from our 
new SIG chair. For those of you who were unable to attend Cincinnati, Kit Trim (our terrific SIG chair for 
the last few years) officially turned the position of SIG Chair over to Joe Whatley (formerly our Special 
Projects coordinator). Fortunately Kit will still be with the OA SIG as the new Special Projects coordinator. 
Thank you Kit for all of your hard work and leadership, and welcome Joe. 

August will be a busy issue with information about the SIR process and an article to update you on the 
status of the SIG Tape. September and October will be great issues highlighting a number of technical 
articles submitted by our readers. I invite you to stay with us for more great information sharing. 

Regards, 

Therese LeBlanc 
OA Newsletter Editor 
275 London Place 
Wheeling, IL 60090 
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MODIFYING THE STANDARD "TWO CALENDAR" 

PRINT OPTION IN TIME MANAGEMENT 

Trace G. Roth, O.H. Materials Corp. 


I have modified the time management print options week’s schedule (WS) 
and two calendars (TC) so that they will only print a time window for 
the week or day according to a start time and end time specified by the 
user. This replaces the standard options’ 24 hour print window. 

Here are the new name data commands for the options WS and TC on 
each 

TMxx_PRINT form. 

WS 

CAL PRINT WEEK_SCH\FORM TMPRINT_TIME\IFEXIT\DO 
TMPRINT_TIME 

TC 

FORM TMGETSEC\IFEXIT\CAL PRINT TWOCAL\FORM 

TMPRINTTIME 

\IFEXIT\DO TMPRINT_TIME 

There is an extra argument form that is called with these options that 
allows the user to enter a starting time and and ending time for their 
time window. This form looks like this and contains the following name 
data. 


Time Management Print Time Window Selection 
Schedule Starting Time: 8:00am 
Schedule Ending Time : 5:15pm 

.TYPE 

ARG /OVERLAY/HARD='Time Management Print Time Window Selection' 
.TYPE 

/P0ST='GET #START_TIME=START_TIME\GET #END_TIME=END_TIME' 
START_TIME 

/VALID=CAL$TIME_CHECK:"START_TIME"/PUT_SAVE=#SM_BTIME 
END_TIME 

/VALID=C_TIME,END_TIME"/PUT_SAVE=#CAL_MTNG_ETIME 

Once this information, start and end time, is received, the command file 
TMPRINT_TIME.COM is run. This command file runs a basic program. 
TMPRINT_TIME.EXE. that only writes the records in the selected time 
window. 

Output from both of these options is shown here. If you like this type of 
output, please add these changes to your system. I believe that this is a 
great improvement over seeing all 24 hours output. 
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I would be most happy to send you this information electronically if so 
desired. Please let me know your preference. 

Trace G. Roth 
Software Analyst 
O.H. Materials Corp. 

Findlay, OH 

(419) 423-3526 x4152 

Sample output of WS print option. 

Schedule for the Week of 12-Jan-1988 


Monday Tuesday Wednesday Thursday Friday 

ll-Jan-1988 12-Jan-1988 13-Jan-1988 14-Jan-1988 15-Jan-1988 


8:00am 

1 

1 


1 

Todo Sessi | 

1 


8:15am 

1 

1 


1 

*** 1 

1 


8:30am 

1 

1 


1 

*** 

1 


9:00am 

1 

1 


1 

*** | 

1 


9:15am 

1 

1 


1 

I 

1 


9:30am 

1 

1 


1 

A1 Shortcu j 

1 


9:45am 

1 

1 


1 
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1 


10:00am 

1 

1 
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kkk 
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1 
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1 
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10:30am 

1 

1 


1 

WP I I Tra I 
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10:45am 

1 

1 


1 
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I 


11:00am 

1 

1 


1 
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11:15am 

1 
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1 
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11:30am 

1 

I 


1 
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11:45am 
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1 


1 
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12:15pm 

1 
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I 

1 

1 


12:30pm 

1 

1 


1 

1 

1 


12:45pm 
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# signify meetings in schedule. 


Sample output of TC print option 


Schedule for Tuesday 12-Jan-1988 
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ROTH 

Time Description 


NAAB 

Time Description 


8:00am 

8:00am 

TRAVEL TO DIGITAL OFFICE; 1701 

8:15am 

8:15am 

'k'k^c 

8:30am 

8:30am 

*** 

8:45am 

8:45am 

*** 

9:00am 

9:00am 

*** 

9:15am 

9:15am 

*** 

9:45am 

9:30am 

#W0RKSTATI0N SEMINAR 

10:00am 

9:45am 

*** 

10:15am 

10:00am 

'k'kic 

10:30am 

10:30am *** 

10:45am 

10:45am 

*** 

11:00am 

11:00am 

TRAVEL FROM DIGITAL BACK TO OH 

11:15am 

11:15am 

*** 

11:30am 

11:30am 


11:45am 

11:45am 

*** 

12:00pm 

12:00pm 


12:15pm 

12:15pm 

*** 

12:30pm 

12:30pm 

*** 

12:45pm 

12:45pm 

*** 

1:00pm 

1:00pm 


1:15pm 

1:15pm 


1:30pm 

1:30pm 


1:45pm 

1:45pm 


2:00pm 

2:00pm 


2:15pm 

2:15pm 


2:30pm 

2:30pm 


2:45pm 

2:45pm 


3:00pmTM Meeting with 

Sharon Thomas 3:00pm 


3:15pm *** 

3:15pm 


3:30pm *** 

3:30pm 


3:45pm *** 

3:45pm 


4:00pm 

4:00pm 


4:15pm 

4:15pm 


4:30pm 

4:30pm 


4:45pm 

4:45pm 


5:00pm 

5:00pm 



# sig schedule. 


Vr Jc ★ 'k ★ -k ★ ^ Jc ?*r ^ * -fc * ★ ★ •& 


TMPRINT_TIME.SCP 

Modified from TMPRINT.SCP by Trace G. Roth on November 4, 1987 

O.H. Materials Corps 

This script is used to print the CALENDAR.TMP file which has been 
produced by the CAL PRINT function. 
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</></></></></> 


! Modified so that a time window can be specified so that 12am 

! to 12pm is not printed. User will specify starting and ending 

! times so that only a specific window of time is printed. 

GET OA$DCL='START_TIME == #START_TIME 
GET OA$DCL='END_TIME == #END_TIME 
DUMP CALENDAR.TMP 
COMMAND OA$LIB:TMPRINT_TIME.COM 
GET #PRINT_FILE=OA$DIR%WH0LE["CALENDAR.TMP"] 

.IF #PRINT_FILE EQS "" THEN .GOTO NO_FILE 

GET #PRINT_LISTFILE="TIMEMGT"/MAKE_FILE_NAME #PRINT_LISTFILE,"TIMEMGT" 
GET #COPIES="1"/GET #QMENU="-2" 

DO WPPRINT 
PURGE "CALENDAR.TMP" 

.EXIT 

•LABEL NO_FILE 

DISPLAY There are no items to print. 

.EXIT 


* * * * * * * * * ** * * * * * * * * * 


$! TMPRINT_TIME.COM Trace G. Roth November 4, 1987 

O.H. Materials Corp. 

! Command file called from TMPRINT_TIME.SCP on 0A$D0 

! Runs BASIC program to strip off unwanted times in calendar output. 

! 

RUN DISK$SYSTEM:[ALLIN1.BASIC]TMPRINT_TIME 
RENAME OUT CAL.TMP CALENDAR.TMP 


******************** 


1! TMPRINTTIME. Trace G. Roth November 4, 1987 

! O.H. Materials Corp. 

! 

5 MAP (R) STRING R$=80 
! 

! open output file from time management for input. 

! 

10 OPEN "CALENDAR.TPM" FOR INPUT AS FILE #3, & 

ORGANIZATION SEQUENTIAL VARIABLE, RECORDSIZE 226 

! 

! open output file. 

! 

OPEN "OUT_CAL.TMP" FOR OUTPUT AS FILE #2, & 

ORGANIZATION SEQUENTIAL, & 

ACCESS WRITE, MAP R 

! 

! get start and end input on form tmprint_time 

I 

CALL LIB$GET_SYMBOL ("START_TIME",SLEN(START_TIME$) 

SLENGTH = LEN(START TIME$) 
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IF SEG$(START_TIME$,1,1) = " " 

THEN IF SEG$(START_TIME$,SLENGTH-1,SLENGTH) = "am" 

THEN START_TIME$ = SEG$(START_TIME$,1,SLENGTH-2) + "am" 

ELSE START_TIME$ = SEG$(START_TIME$,1,SLENGTH-2) + "PM" 

END IF 

ELSE IF SEG$(START_TIME$,SLEGNTH-1,SLENGTH) = "am" 

THEN START_TIME$ = SEG$(START_TIME$,1,SLENGTH-2) + "am" 

ELSE START_TIME$ = SEG$(START_TIME$,1,SLENGTH-2) + "pm" 

END IF 
END IF 

CALL LIB$GET_SYMBOL ("END_TIME",END_TIME$) 

ELENGTH = LEN(END_TIME$) 

IF SEG$(END_TIME$,1,1) = " " 

THEN IF SEG$(END_TIME$,ELENGTH-1,ELENGTH) = "am" 

THEN END_TIME$ = SEG$(END_TIME$,1,ELENGTH-2) + "am" 

ELSE END_TIME$ = SEG$(END_TIME$,1,ELENGTH-2) + "pm" 

END IF 

ELSE IF SEG$(ENT_TIME$,ELENGTH-1,ELENGTH) = "am" 

THEN END_TIME$ = SEG$(END_TIME$,1,ELENGTH-2) + "am" 

ELSE END_TIME$ = SEG$(END_TIME$,1,ELENGTH-2) + "Pm" 

END IF 
END IF 

WHEN ERROR USE ERROR_ROUTINE 

i 

! get first 9 records from time management file. 

! these are the page header records 

i 

15 FIRST_RECS%=0% 

UNTILL FIRST RECS2 = 2% 

GET #3 

MOVE FROM #3,REC$=80 
R$=REC$ 

PUT #2 
GET #3 
R$=" " 

PUT #2 
PUT #2 

FIRST_RECS%=FIRST_RECS%+1% 

NEXT 

UNTIL FIRST_RECS% = 4% 

GET #3 

MOVE FROM #3,REC$=80 
R$=REC$ 

PUT #2 

FIRST_RECS%=FIRST_RECS%+1% 

NEXT 
GET #3 
R$ = " " 

PUT #2 

! 

! read until starting time record is reached. 

! 

20 UNTIL CALTIME$ = END_TIME$ 

GET #3 

MOVE FROM #3,REC$=80 
CALTIME$=SEG$(REC$,1,7) 
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NEXT 

! 

! write time records until ending time is reached. 
! 

UNTIL CALTIME$ = END_TIME$ 

R$=REC$ 

PUT #2 
PUT #3 

MOVE FROM #3,REC$=80 
CALTIME$=SEG$(REC$,1,7) 

NEXT 

! 

! write page footer informion. 

! 

R$=" " 

PUT #2 
PUT #2 

R$="# signify meetings in schedule." 

PUT #2 
END WHEN 

HANDLER ERROR_ROUTINE 
CLOSE #3 
CLOSE #2 
END HANDLER 
40 END 


A REQUEST FOR HELP WITH MAIL MERGE 

Karen Paulaski, Collier County Clerk of Courts 


NOTE FROM THE EDITOR: 

The following article was taken from a letter sent to me requesting information and/or help. I did not have 
a solution for Karen and suggested she publish her inquiry in the newsletter. If you can be of assistance, 
please contact Karen at the address published at the end of the article. 

Regards, 

Therese 

******************************************************************************** 

I am interested in obtaining information about mail merge functions for use in our VAX 8550, COBOL 
environment. The crux of the matter is, we do not want to become involved with an entire work processing 
system, only a mail merge function which we can incorporate into our existing menu driven Court System. 
We need to print data forms such as Warrants and Subpoenas for our Court System, by merging an input 
data file with the numerous forms necessary for government activity. If you have any information on 
software packages, or have had experience with similar functionalities - or know of anyone who has, I would 
greatly appreciate hearing from you. More information on our needs is as follows. 

Currently our system’s set up as a series of menus from which the users may select functions from pull 
down windows, and enter data interactively. The data is written to a batch command file, and passed to the 
batch section of the program where it is read and reported on accordingly. We want to keep the 
functionality the users are accustomed to and have them select the forms to be processed, and any other 
selection criteria, interactively from a menu. We would then like to be able to write a COBOL program to 
create the input data file, and create a forms file. These two files would be submitted to the mail merge in 
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batch and the forms would be created. 

We will have to accommodate variable sizes of output files (10 to 5,000) blocks and be able to output a 
variable number of forms (1 to 500). 

If you have any information regarding such a function you can contact me at (813) 774-8945 or write to: 
Karen Paulaski 

Collier County Clerk of Courts 
M.I.S. Division 
P.O. Box 413020 
Naples, Florida 33941-3020 

Thank you! 


COMING SOON... SIR FEEDBACK FROM DEC 
AND NEW SIR LIST TO VOTE ON! 


SIR (system Improvement Request) Bulletin: 

We had an exciting session in Cincinnati listening to DEC’s response to our last list of top 25 + SIR items. 
You’ll have the opportunity to see what all the excitement’s about for yourself in the August issue. We’ll 
reprint the SIR’s and their responses for you to see. 

And we’ve got a whole new list of SIR items just waiting to be voted on. They will be listed in the August 
issue along with a ballot so you can let DEC know what’s important to you. The deadline for returning 
those ballots will be around September 1st, 1988... so you’ll have to act fast. Stay tuned for more next 
month. 


THOUGHTS ON CINCINNATI 

Joe Whatley, AO SIG Chair 


It is impossible to express my gratitude to all of the people who helped make Cincinnate a succes for the 
OA SIG. However, since I generally ignore the impossible. 

THANKS to the DECUS staff for doing what you do best — and you keep getting better. 

THANKS to the speakers and session chairs — you made the success happen daily. 

THANKS to the many Digital support people on the exhibit floor, our campground, our suite and the 
special demonstration room — you made the trip really worth it. 

THANKS to the members who came to sessions to learn and share experiences with each other — you are 
truly the heartbeat of the symposia. 
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and finaly 


THANKS to the energetic and enthusiastic volunteers of the OA SIG 
we ran out of jobs to give you - so, we made some more. 

Joe Whatley 
OA SIG Chair 


you kept volunteering even when 
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PRO Section 

PALETTE ON A PRO 350 
By Peter Edmonds, Perth, Australia 

This article describes personal experiences with the basic 2D drafting tool of this Australian 
CAD/database system, which I have been operating for over 2 years. 

My Operating Environment 

I operate a single-person consultancy in Naval Architecture and Ship Design/Drawing work, mainly in 
small commercial vessels (up to about 30 m), for construction in Western Australian yards. A 
considerable proportion of my work is not drawing production (and hence non-Palette); typically 
stability submissions, scantling determinations, weight calculations, etc. 

I run Palette on a PRO 350, with colour screen, and plot drawings up to A3 size on a HP 7475A plotter; 
this plotter also appears as a DEC LVP16. Larger drawings are plotted by a local bureau, where 
Palette is operated on a contract drafting basis. I am, however, working towards buying and setting up 
a (superseded) larger plotter (Houston DP9), and adapting the driver software to suit my system. 

Palette - General 

Palette is a suite of CAD/Database software modules, which starts around the basic 2D CAD module, 
and extends into modules for advanced drafting, 3D Wireframe, 3D Colour-Shaded Image, spatial and 
external databases, other CAD applications, and user applications. 

Palette originated in Australia, and was launched onto the market in 1978 by Dr Michael McLean, its 
designer. Since then, it has been sold extensively in Australia and the United States, and is now sold in 
28 countries. It grew up around the PDP-11 and the VAX computers, with all current development 
related to the VAX environment. The main development of Palette is now taking place in the United 
States. 

Whilst there are many extensions from the basic 2D drafting module, my experience of these is very 
limited; restricted to a little work on 3D Wireframe modelling. My operations are most unlikely to 
support any of the other major modules beyond the Independent Program Interface. This interface will 
allow me to run my own applications without leaving Palette. 
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[Perhaps some other DECUS member would like to comment on experience with other modules. I look 
forward to Newsletter contributions on this.] 

An early installation of Palette was at Carrington Shipyard, Newcastle, New South Wales. When I 
visited the site several years ago, I was most impressed by the way it was working within my own 
technology of ship design. At this visit, I had the 3D system demonstrated by Mike McLean, prior to it 
being handed over to the shipyard for production use. 

Why My Installation? 

The availability of the PRO 350 as a "personal PDP-11", the downwards migration of the software 
onto this machine, and licence pricing policy (one-off sale, with optional software support), and a used 
PRO 350, resulted in an "affordable" access to a system that had proven iteslf in my own technology. 
The move into CAD also offered the prospect of enhancing my drawing production capacity, without 
having to find a suitably skilled person in times of heavy demand, then trying to find gainful work for 
draftsman (men? persons?) in times of lesser demand. 

Operation of the System 

Palette is primarily keyboard command operated, but can use digitizer tablets, both for cursor 
positioning and commands. On the PRO, the numeric keypad provides 8-direction cursor movement, 
with speed control, in addition to the 4-direction movement with the standard cursor control keys. 

In my installation I have stayed with the pure keyboard mode. My reasons for this were that the 
tablet would not provide full coverage readily of the total command structure (eg number input: back to 
the keyboard, or move through a "keypad" on the digitizer tablet), and that it also required eyes onto 
the tablet to operate; it would also cost another $2000 or so. I believed that the desirable path was to 
enhance my keyboard skill and touch type the comands and cursor positioning, leaving eyes free for 
watching the screen and the source material. Even though my touch typing is not as good as I would 
like it to be (I am around 30 wpm), I am quite happy with my choice, and have no wish to use a tablet. 

The command structure is very well suited to learning, using combinations of meaningful letters. For 
example, the command LHL300;D is Line Horizontal Length 300 (; to terminate number) (mm) Draw. I 
find the system particularly attractive to use where I know the numbers (coordinates, lengths, etc) for 
what I am drawing. 

Some items just have to be remembered. For example, C2 draws a circle (obvious from the C part) with 
a previously defined circle centre (CC) and passing through a previously defined circle point (CP). 

The French Curves facility (for which I need a workable system in my environment) works very well, 
running a curve explicitly (no "best fit") through the data points, with choices of end conditions; 
tangential to an existing line, straight, or general. It also provides area and centroid calculations, at a 
few keystrokes; both of which I find very useful facilities. 

Learning to Use the System 

Just before I purchased my system, I enrolled in a weekly class at one of our local Technical Colleges, 
where Palette is used as an introductory/training CAD system. This gave me some formal instruction, 
and practical operation under supervision, so I did not elect to have any formal training from Palette. 

After I had started up my own system, I very soon passed most of what was being covered in class. I 
used the time to get some experience on the 3D Wireframe module. 

I believe that an ideal training is a small amount of formal instruction, followed by working on real 
jobs, with ready access to experienced operators. My development has been particularly isolated, but 
Palette Systems now have a support person in Perth, who has proven most useful; mainly telephone 
queries and supply of documentation. 
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The User Society has yet to get functioning in Perth, despite an attempt just after I bought my system. 
This makes me realise how lucky we are with DECUS. 


Alternative Systems 

At the time of my purchase, an IBM look-alike, suitably optioned up, and AutoCad fully optioned up 
(or VersaCad), would have been approaching my offered outlay on the used PRO, the software, and 
the plotter. These other CAD systems had not proven themselves in my technology,which I regarded 
as very important. The local vendor swung the deal with an offer to buy the system back after 3 months 
(less an appropriate rental) if I was not happy with it. The buyback time came and passed with not 
the slightest wish for me to return the system. 

I have since operated AutoCad over a TAFE course, to give me some experience of this "widespread 
industry standard" system. I found the shifting of menus tiresome, after the direct access to all the 
commands available with Palette. As this was the second CAD system I was learning, I was forever 
thinking "What is ’Autocad’ for (the Palette command I wanted)?" The use of the function keys, with 
no prompting beyond the keyboard labels, helped to avoid some menu shuffling. 

Although at that stage my impression was probably severely coloured by my experience with Palette, 
and relative lack of experience with AutoCad, I was always very glad to get back to Palette. 

Experiences, Strengths and Weaknesses. 

Palette is a system where one can start with a fairly small inventory of knowledge of its operation, and 
then add to this as the need arises. (Even now, I have not used the "grid" capability.) 

I will never know the productivity gains that the change to CAD has achieved, as my basis for 
"before" was not sufficiently quantified. The gains depend very much upon the mix of types of work 
involved, and the inventory of drawings and symbols built up. 

Palette works very well on repeating (with or without alteration) of drawing elements, as well as on 
"numerical" input, as outlined previously. It is at its worst (for me) on freehand sketching, 
particularly producing "pretty" drawing elements. 

I greatly appreciate being able to generate drawing text at keyboard speed, also the quick and clean 
(minimal repairs) erasure of drawing elements. Also, I appreciate the freedom from dodging (or 
smudging) wet ink on the drawing, and of not having to repeat the drawing of elements. Some of this 
has been well reinforced by a spate of "traditional" drawing. 

I have been surprised at how much I have been able to generate drawings within the limits of the A3 
plotter. Instead of multiple views on one drawing, I often generate a booklet of A3 drawings; very easy 
to flick through the pages to find the part you require. It is frequently possible to hold elements of a 
final large drawing on a series of A3 sheets, or to dump parts of a larger drawing onto a series of A3 
sheets for progress plots prior to completion, and then plot the final drawing at full size. Reduced scale 
plots can be used to extend the scope of the A3 plotter. 

With my use of CAD, I came to realise that the scale of a drawing is often governed largely by the 
scale at which the draftsman is prepared to work, and a reduced scale can provide adequate definition 
for the user. A limit I have found here is on the text size, as this can be scaled down as a drawing or 
element is reproduced at a reduced scale. On scales, I have strongly resisted any moves away from the 
1:10, 1:20,1:25, 1:50 and multiples. 

One limitation I have often found with scale and drawing size reduction is the decreasing space 
available for text, as the text size cannot be reduced too far. 

Palette’s smallest standard text size is 2.5 mm. For a period, I used the designated size of 2 mm, but I 
found that this led to user complaints. I now use the 2.5 mm size as my working minimum text size. 
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I have been able to use nominated scale factors to facilitate copying from existing drawings, where 
these form the basis for further drawing work (additions and alterations, etc). For example, working 
from an existing 1:24 drawing, to generate a new 1:50 drawing, I would initially set the scale as 
1:2.0833 (1:50 / 1:24), copy the existing items using old drawing millimetre sizes, then reset the scale to 
1:50, and add new item in finished job millimetre sizes; no multiplications during drawing required. 
This would, of course, work if one were digitizing off an existing drawing, too. 

Palette allows the ready customization of function keys for particular commands or macros of command 
strings. For instance, I have extended the supplied single-key selection of drawing layer to single-key 
selection of the commonly-used line thicknesses and line textures, which I frequently change during 
drawing operations. 

A personal feature of the CAD operation is that I enjoy the challenge of finding the technically 
elegant CAD solution to the immediate drawing requirement. Part of this arises because there are 
frequently several different ways of using the command structure available to produce the required end 
result. 

A secondary benefit of my purchase of a Palette system is that it has introduced me to quite a powerful 
computer system (much potential still to be tapped), and to the world of DECUS. Hence this 
contribution. 

Peter Edmonds 

Perth, Western Australia 

Editor's note - I contacted Palette Systems for a little more information about their software. While 
they are not actively marketing Palette for the PRO any longer , they STILL will ship you a copy if 
you want it. Palette requires a PRO 350 or 380 with the extended bitmap option. A color monitor is 
optional but recommended. A data tablet is ALSO optional but recommended. Palette supports the HP 
plotter series, as the output device 

Palette Systems is located at. Unit 6, 

Northwood Executive Park 
10 Northern Blvd. 

Amherst, NH 03031 
(603)595-7673 

Feel free to contact them for further information. 


Updates to the PRO Public Domain Software Collection 

By Gary Rice, PC SIG Newsletter Editor 

Since the last update, the following software has been added to the collection. 

Catalog 

_# Description 

S84-2 Force is a program that will force characters to another keyboard. ’Detach’ is a patch that will 
enable users to reconnect to a task after a modem hangup. 

ALSO: 

Daofwk.* - Originally written by Jeff Hamilton. Will return the day of the week in <exstat> 
for the indirect command processor (...at.). 

Duplex.* - Source and command files for Duplex. This version has been completely revised since 
Martin Heller’s original copy appeared. I have added large ring buffers, taken the disk access 
routines out of the ast level and added support for Hayes compatible smart modems... The code 
has been modified so many times that it needs a major rewrite to neaten the code — a task I 
have yet to find the time for. If there are any volunteers, please let me know, I can probably 
find some time. And will most likely get around to it within the year if no-one else does. Even 
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with data capture enabled and no error checking. Duplex 5.0ejc will run at 4800 baud with less 
than 2% received character errors. 

Article.txt - Newsletter article to be submitted to the MULTI-TASKER. 

Frg.* - Disk Fragmentation Utility - similar to HOL only it shows a histogram of contiguous 
blocks on the disk. 

Priv.* - Set terminal privileged with password protection. 

WHO.* - Shows logged on users and current tasks.... 

RTCLI.* - An alternate CLI for V4.n, V2.n RTCLI allows a non-privileged user to run privileged 
code or code at a very high priority for real-time or other time-critical applications. User is 
restricted to RUN [GGG,MMM]??????.TSK, ABO, WHO, RMD or MCR/DCL to exit to the 
appropriate ’normal* CLI. Excellent framework for creating you own CLI's. 

LGOCLI .* - An alternate CLI for V4.n, V2.n LGOCLI allows users to type WHO, RMD, HELP 
and HELLO from logged out terminals without having to log-in. More sophisticated version 
(which simply means un-debugged and regularly crashes my system) will also allow BRO and 
ABO with password protection. Very handy for one pool is almost gone and someone hangs the 
system to where you can’t even logon.... 

Hplib.* - Plotter library(s) for an HP7220C 8-pen plotter. 

Testhp.* - Program which excercise the library and allows direct control of the plotter from a 
terminal. 

*mac.cmd - Files to allow RMD M page to offer the option of setting the memory size.... the 
suggestion in the MULTI-TASKER several months ago of changing $SYSIZ is VERY 
DANGEROUS!!!! This works just as well and WILL NOT corrupt the exec. It also offers 
support for 132 col. M page display on VT102, VT105, and VT125 type terminals. We have 4Mb, 
and a normal RMD is absolutely worthless. 

EXEcute.cmd - An indirect command file that will take F77 source code and produce, using 

F77 and TKB, the task image. Default mode asks which of many options are required. 
Compressed mode allows option specification in the command line. >EXE ? command produces 
syntax help message screen. 

Graphit.* - F77 source program for a simple HP7220C graphing task. There is no documentation. 

1 diskette; Sources included; NO objects; SOME task images 
MACRO, FORTRAN-77 


S84-3 **** BUG VERSION 2.0 **** Some insight -- what actually does bug do? It makes a copy of the 
specified task file, and ’’implants” some interface code in the task’s stack (safely away from 
lower and upper limits). For this reason the task has to have at least the default stack size. 
The starting address of the task is suitably changed as if it were built with a debugger. Then 
the task being ’’bug’ed "talks" to ...BUG during the debugging session. Register info, etc. is 
passed between the two tasks during the debugging session. Note — no special preparation is 
necessary for the task being debugged (you can "bug" EDT if you want). The original task file is 
left untouched. 

ALSO: 

TIZ - Task Image Zapper 

CALC - Calculator and radix converter. 

BRU - BRU command line builder. 

1 diskette; sources included; SOME objects; Task images included 
MACRO, FORTRAN-77, Indirect Command File processor 


S84-4 HEX - Microprocessor object file management utility The HEX utility is designed to manipulate 
ASCII hex formatted files as output by cross-assemblers and linkers for microprocessors (Z80, 
8085, 68000, etc.). HEX supports all of the popular ASCII hex formats: Intel, Motorola, 
Rockwell, RCA, TekHex, Extended TekHex, Texas, Mostek, Hex-space, Octal-space, and TCI, 
plus several binary ones: Whitesmiths', PDP-8 RIM and BIN, and PDP-11 object and task 
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formats. 


2 diskettes; Sources included; NO Objects; NO task images 
MACRO 


F86-11 SLIDES.OUT is a copy of the slides presented at the session. The other files are the indirect 
command procedures, UIC.CMD and WHO.CMD as discussed at the session. Another file, 
named PROJECT.CMD, is a short command procedure which may be useful for displaying 
contents of a short file onto the screen of a VT241, in a manner suited for making slides or 
transparancies for a presentation. 

ALSO: 

The purpose of these files is to demonstrate how one could access the I/O page from Decus C. 
The example accesses a clock/calender card and sets the system time. 

1 diskette; Sources included; NO objects; NO task images 
MACRO, C, Runoff 


Distribution of the Public Domain Library is handled in the following way: After looking through the 
"catalog” and selecting the items you want, send me enough diskettes to hold the software you desire. 
Diskette counts are listed with each catalog entry. Include a return mailer, box, carton, palette, etc. 
sufficiently large to hold the diskettes. Include enough postage to pay for the return trip. I will NOT 
use UPS. Sorry. 1st class mail is recommended, but parcel post is ok. I will then copy the requested 
software for you and send it along. Give me at least a week for ANYTHING (plus travel time). Large 
(more that 5 diskettes) orders will likely take longer. Specify the software you want by catalog 
number. 

PLEASE don't ask for "specials". It took a lot of time to put THIS collection together. 

Contributions are also welcome. However, if the work is NOT YOURS TO GIVE, please DON’T. 

If you are submitting something to the collection, please include a signed copy of the following 
statement with your submission: 

The program that I am submitting to the Public Domain titled 

does not contain technical data/information that is 
proprietary , classified under US Government Secrecy Laws, controlled by non-disclosure agreements 
with the US Government or third parties or governed by US Department of State's International 
Traffic in Arms Regulations (ITAR). 

Full and irrevocable permission and consent is hereby given to DECUS to reproduce , distribute and 
publish in whole or in part, in any form and without restriction, this program or revision and any 
information relating thereto. The undersigned hereby warrants and represents that s/he has good and 
sufficient right, interest and title in and to this program or revision and the related information to 
grant such permission to DECUS. 

Send your requests or contributions to: Gary Rice 

McDonnell Douglas 
5555 Garden Grove Blvd, 

Mail code: K20/200 
Westminster, CA 92683 

Please include a daytime phone number. Several software requests that I have received required me to 
contact the requestor before I could send them what they wanted. 
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PRO Software Update 

By Gary Rice, PC SIG Newsletter Editor 

In an effort to keep you informed about software being shipped from various vendors, I began the 
following list in April, 1986. This list was last published in the May, 1988 issue of these Newsletters. 
This updated list reflects information that I have received as of May 21, 1988. An asterisk by an entry 
indicates that the item has changed or been added sine the last time the list was published. The 
changes are highlighted as well. 



List 

Last 

Source 

Still 

P/OS v3 

DEC Software 

Price 

Rev 

of info 

Avail? 

Supported? 

20/20 

495 

1.0.54 

User 

Yes 

UNK 

Athena/Graph 

450 

1.0 

DEC 

Yes 

UNK 

BASIC-11/RT-ll (Replaced - See BASIC-PLUS/RT-11) 



BASIC-PLUS/RT-11 

UNK 

3.0 

DEC 

Yes 

N/A 

CT*OS 

UNK 

1.0 

DEC 

Yes 

UNK 

Design Graphix/Executive 

595 

1.0 

User 

Yes 

Yes 

Easyentry 

995 

3.0B 

DEC 

Yes 

UNK 

FORTRAN IV/RT-11 

495 

2.8 

DEC 

Yes 

N/A 

Installation & Maintenance 

UNK 

3.2 

DEC 

Yes 

Yes 

LOGO 

350 

1.4 

DEC 

Yes 

UNK 

MAIL-PLUS 

N/A 

1.0 

DEC 

No 

N/A 

MJA Accounts Payable 

600 

5.2 

DEC 

Yes 

UNK 

MJA Accounts Receivable 

600 

5.2 

DEC 

Yes 

UNK 

MJA General Ledger 

600 

5.2 

DEC 

Yes 

UNK 

MJA Order Entry/Inventory 

600 

5.2 

DEC 

Yes 

UNK 

MJA Payroll & Personnel 

600 

5.2 

DEC 

Yes 

UNK 

NPL Information Management 

N/A 

1.4 

DEC 

No 

UNK 

Phoenix-PRO 

1795 

1.0A 

DEC 

Yes 

UNK 

P/OS ADCCP Driver 

UNK 

1.0 

DEC 

UNK 

UNK 

P/OS (Diskette) 

N/A 

IB 

DEC 

No 

No 

P/OS (Hard Disk) 

475 

3.2 

User 

Yes 

Yes 

P/OS Hard Disk (Arabic) 

783 

R3.1 

DEC 

Yes 

Yes 

PRO 2780/3780 

53 

1.2 

DEC 

DECUS 

No 

PRO Application Starter Kit 

399 

1.0 

DEC 

Yes 

No 

PRO/Associate 

N/A 

1.0 

DEC 

No 

No 

PRO/BASIC 

195 

1.4 

DEC 

Yes 

Yes 

PRO/Comm (diskette) 

N/A 

IB 

DEC 

No 

No 

PRO/Comm (hard disk) 

195 

3.0 

DEC 

Yes 

Yes 

PRO/CPM-80 

UNK 

1.1 

DEC 

UNK 

UNK 

PRO/Datatrieve 

495 

2.0 

User 

Yes 

Yes 

PRO/DECnet 

250 

2.1 

DEC 

Yes 

Yes 

PRO/FORTRAN-77 Debug (See PRO/Toolkit Symbol 

ic Debugger) 



PRO/IVIS 

UNK 

3.1 

DEC 

Yes 

Yes 

PRO/Laboratory Subroutine Lib. 

300 

1.2 

DEC 

Yes 

Yes 

PRO/NAPLPS 

N/A 

1.0 

DEC 

No 

No 

PRO/Office Workstation 

UNK 

2.0 

DEC 

Yes 

Yes 

PRO/PRODUCER Toolkit 

300 

1.6 

DEC 

Yes 

Yes 

PRO/RDT 

495 

1.1 

DEC 

Yes 

Yes 

PRO/Scientific Subroutine Library 

300 

13 

DEC 

UNK 

No 

PRO/SIGHT 

295 

1.1 

User 

Yes 

Yes 

PRO/SNA 

N/A 

1.1 

DEC 

No 

No 

PRO/Smart Mailer 

53 

1.0 

User 

DECUS 

Yes 

PRO/Toolkit 

520 

3.2 

DEC 

Yes 

Yes 

PRO/Toolkit BASIC-PLUS-2 

495 

25 

DEC 

Yes 

Yes 
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DEC Software 
PRO/Toolkit COBOL-81 
PRO/Toolkit DIBOL 
PRO/Toolkit FORTRAN-77 
PRO/Toolkit PASCAL 
PRO/Toolkit Real Time Library 
PRO/Toolkit Symbolic Debug 
PRO/VENIX 
PRO/Videotex 
Professional CTS-300 
Professional Real Time Lib/RT-11 
PROSE PLUS 
RS/1 

RSX Host Toolkit 
RT-11 

Supercomp-20 

Synergy 

VAX Host Toolkit 
WPS/Plus 


3rd Party Software 

_( V en dor )_ 

D-M-DRIVER for P/OS 
(PROTO SYSTEMS) 

Fingraph 

(Graphic M*I*S) 

it*os 

(Intermation) 

Online Disk Unfragmentor 
(By Hand) 

PRO/Sentinel 
(By Hand) 

PRO/Session Logger 
(By Hand) 

PRO/Text Locator 
(By Hand) 

RDM Relational Data Manager 
(Interactive Technology) 
SATURN-BASE 

(SATURN SYSTEMS) 
SATURN-CALC 
(SATURN SYSTEMS) 
SATURN-GRAPH 
(SATURN SYSTEMS) 
SATURN-WP 

(SATURN SYSTEMS) 
SPSS/Pro 
(SPSS Inc.) 

TKlSolver 

(Software Arts) 


List Source 

Price Rev of info 

495 *2.5 DEC 

495 1.7 DEC 

495 5.2 DEC 

495 1.3 User 

150 2.1 DEC 

200 2.0 DEC 

495 2.0 DEC 

895 1.0 DEC 

995 1.0 DEC 

250 1.0 DEC 

295 2.0 User 

1900 12.0 User 

UNK 3.0 DEC 

550 *5.4D DEC 

N/A 1.28 User 

695 2.0 User 

UNK 3.0 DEC 

695 1.0 DEC 

List Info 

Price Rev Source 


195 V2/V3c Vendor 

N/A 2.0 DEC 

UNK 5.2 User 

59 *2.0a Vendor 

47 1.0 Vendor 

29 2.0 Vendor 

43 1.1 Vendor 

995 4.1C User 

750 1.4 Vendor 

500 3.0 Vendor 

500 *2.1 Vendor 

600 5.0 Vendor 

UNK 1.1 Vendor 

N/A 1 (2A) User 


Still 

P/OS v3 

Avail? 

Supported? 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

N/A 

Yes 

UNK 

Yes 

N/A 

Yes 

N/A 

Yes 

Yes 

Yes 

UNK 

Yes 

Yes 

Yes 

N/A 

No 

UNK 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 


Still 

Avail? 

Yes 

P/OS 

y22_ 

Yes 

No 

UNK 

Yes 

UNK 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

No 

UNK 


If you have received a shipment of software in the last month (and you DIDN’T get it in a fire sale), 
please compare the documented REV level to the one I have listed. If your software is more recent (or it 
isn't listed at all), please let me know so I can update the list. Also, if the source of my information is 
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listed as "DEC”, I would appreciate hearing from a user, since I’ve found that hearing about it from 
DEC doesn’t always mean that it is actually shipping. I will publish a new list each time it changes. 

You can contact me at: McDonnell Douglas 

5555 Garden Grove Blvd. 

MS: K20/200 
Westminster, CA 92683 
(714) 952-6582 


PROgramming Quickie 

By Gary Rice, PC SIG Newsletter Editor 

When I installed P/OS version 3,1 found that several of my favorite DECUS programs (such as REI - 
the file REIncarnator, and CVL - the Change Volume Label program) as well as some of my OWN 
programs no longer functioned. When they attempted to do Logical I/O to the disk, the QIO call 
returned an error. 

I tried many things to fix the problem and finally gave up. Work arounds were the best that I could 
come up with. 

Recently I was discussing the problem with someone I know. As a result of that conversation, I obtained 
a code fragment that demonstrated a way to restore functionality to logical QIOs. After "fluffing" out 
the fragment, here is what I ended up with. 

; DOLOGQ.MAC This subroutine allows a privileged task to do Logical QIOs 
; to a mounted disk when running P/OS v3.0 or above 

/ 

; AUTHOR: Anonymous 

/ 

; CREATED: Unknown 

/ 

; REVISIONS: March 24,1988 - Turned fragment into a subroutine (Gary Rice) 

; INPUTS: None 

; OUTPUTS: None 

; NOTES: This subroutine enters "SYSTEM STATE" Therefore, linking MUST 

; include /PR:0 to make the task privileged enough to do it 

/ 

.********************************************************** 

/ 

.TITLE DOLOGQ 

.IDENT /V1.0/ 

/ 

; Global definitions 

.GLOBL DOLOGQ 

/ 

; Macros 

•MCALL GTSK$S,WIMP$S,SWST$S 

/ 

; If we are on P/OS V3.0 or later, we must have the T4.LIO bit set in 
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; T4.STS in order to perform logical I/O to a mounted volume, or all 
; IO.RLB/IO.WLB activity will fail with IE.PRI errors. The use of 
; executive vectoring should let this task function on P/OS V2.0 and later. 

; The T4.LIO bit is undocumentedin the Toolkit manuals, but is described in 
; the fiche. 


DOLOGQ: 

SUB 

#16.*2,SP 

; We need a 16 word buffer 


MOV 

SP,R5 

; R5 => buffer 


GTSK$S 

R5 

; Get task parameters 


BCS 

10$ 

; If it faled, just give up 


WIMP$S 

#GI.FMK,R5,#9. 

; Get system feature masks - since this 
; subfunction was implemented beginning 
; with P/OS V3.0, it will fail on older 
; versions of P/OS 


BCS 

10$ 

; If CS, must be older than V3.0 


SWST$S 

#20$,#20$ 

; Set bit in system state 

10$: 

ADD 

RETURN 

#16.*2,SP 

; Fix up stack 
; All done 

20$: 

MOV 

@#$VECLC,R4 

;; R4 => $Stack 


MOV 

$TKTCB-$ST ACK(R4 ),R4 ;; R4 => our TCB 


BIS 

RETURN 

.END 

#T4.LIO,T.ST4(R4) 

;; Set logical I/O privilege bit 
;; All done 


To use it, simply "CALL" it from any program that needs to do Logical QIOs to a mounted disk and is 
running P/OS version 3.0 or above. The code CAN be linked into P/OS v2 images. With P/OS v2, it will 
simply do nothing. 


The following test program in FORTRAN demonstrates that the MACRO routine actually works. 


C 


BYTE BUFFER(512) ! A1 block buffer 

INTEGERS PARM(6), STATUS(2) ! QIO variables 


CALL GETADR (PARM(1),BUFFER(1)) 
PARM(2) = 512 
PARM(5) = 1 

CALL WTQIO ("1000,1,1„STATUS,PARM) 
TYPE * STATUS 
CALL DOLOGQ 

CALL WTQIO ("1000,1,1 „STATUS,PARM) 

TYPE * STATUS 

END 


! Get the address of the BUFFER 
! BUFFER is 512 bytes long 
! Set to read block 1 
! Try to read the block 
! Will ALWAYS fail on P/OS v3 
! FIX it 

! and try again 
! Works this time! 


There are some special files that you will need to include in your LINK command to get the program to 
resolve all of the symbols and routines that DOLOGQ uses. Those files are EXELIB.OLB and POS.STB. 
They can be found on the P/OS base system diskette labeled "PRODCL2" in the directory 
[ZZPRIVDEV]. 


The command file that I used to link the previous FORTRAN program which I called QIO.FTN is 
listed on the next page. 
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QIO/PR:0=QIO,DOLOGQ 

LB:[1,5]EXELIB/LB 

LB:[l,5]POS.STB/SS 

LB:[l,5]PROF77/LB 

/ 

; EQUATE P/OS SYMBOLS TO LUNS 

GBLDEF=TT$LUN :5 
GBLDEF=WC$LUN :0 
GBLDEF=MS$LUN:5 
GBLDEF=FL$LUN:0 
GBLDEF=HL$LUN :0 
GBLDEF=MN$LUN :0 

; DEFINE EVENT FLAG 

GBLDEF=TT$EFN: 1 

; DEFINE CLUSTER SCHEME 

CLSTR=PROF77,POSRES,RMSRES:RO 

/ 

// 

Send me your own PROgramming Quickie and I will publish it here in this on-going column in these 
Newsletters. (RX50 Please) 


Workstations Section 


A New Workstation Focus Within DECUS? 

By Mark Sebern Sebern Engineering Inc. Cedarburg, Wl 53012 
(414)375-2200 

There was a lot of workstation activity at the Spring Symposium in Cincinnati, including a number of 
sessions presented by the PC SIG and other DECUS SIG’s. There was also a lot of interest in the 
DEC windows "technology demonstration" presented in the Digital exhibit hall. 

One topic of discussion involved the best way of coordinating the various DECUS activities related to 
workstations of all types. Suggestions ranged from beefing up the coordination activities of the current 
Workstation Working Group (which was formed after a widely attended BOF at the Nashville 
Symposium), to the possible formation of a Workstation Special Interest Committee (SIC). The pro’s 
and con’s of the various alternatives were discussed, and the SIG Council seems to be moving in the 
direction of putting together a "woods meeting" for representatives from the various SIG’s which have 
an interest in workstations. 

Unfortunately, a lot of this discussion took place late in the week, and many interested DECUS 
members may have missed the chance to participate. If YOU have an interest in workstations 
(including VAXstation, Macintosh, and other vendors), please let your SIG steering committee know 
RIGHT AWAY. For the PC SIG, the people to contact arelisted on the next page: 
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Lynn Jarrett 
PC SIG Chair 

San Diego Union-Tribune Pub. Co. 

350 Camino de la Reina 
San Diego, CA 92108 
(619) 293-1130 

Tom Hintz 

PC Working Group Chair for Workstations/Macs/Pro 
University of Florida 
IF AS Computer Network 
Bldg. 120 

Gainesville, FL 32611 
(904) 392-5180 

Again, the Cincinnati Symposium was an exciting one for workstation activity, and the PC SIG sessions 
were very well attended. Whether you made it or not, your opinions on how DECUS should address 
this emerging technology are very important. Let your voice be heard! 
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From the Editor: 

Well, at the next-to-last minute I had to cancel my trip to Cincinnati. First 
DECUS I've missed since Miami Beach! So I can't give you a first-hand report 
of what went on. Apparently a lot of "regulars" didn't make it to this one, but 
fortunately Milton Campbell, our stalwart symposium coordinator was there 
and will give us his trip report. A brief one-pager appears in this issue, and a 
detailed account of the RT-11 Sessions follows next month. Scott Harrod took 
me at my word and sent a condensation of his idle thoughts about TeX, 
Newsletters, and the future of RT. (I also understand that Scott was one of 
the highlights of the "User Speakout in Cincinnati.) Gary Sallee's Introduction 
to KERMIT/RT is concluded in this issue with a description of the KERMIT 
protocol and file transfer. Gary has also provided a preview of the SCURT LUG 
meetings. For those of you who are in Southern California or can make it 
there at the times mentioned, those meetings are well worth attending. 

Keep sending those cards and letters to 

John M. Crowell 
RT-11 Newsletter Editor 
Multiware, Inc. 

2121-B Second St. #107 
Davis, CA 95616 
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REPORT FROM CINCINNATI 
Part I 

Milton Campbell 

RT-11 SIG Symposium Coordinator 


This is an administrative report, if I get time, I will do 
something later about the content of some of the sessions. 

The good news is that there was a broom closet available that 
had only one chair. I was able to reschedule the RT-11 sessions 
into it. The bad news is that RT-11 session attendance was 
about the same as Nashville, so I had to put all the sessions 
back in their original rooms. 

Seriously, session attendance was about the same as recent 
spring symposia. The attendance at the RT-11 sessions I went 
to ranged from 15 to 50. The worst attendance I heard about 
was one that had only 7 in the audience, only 2 or 3 other 
sessions had under 15. While I do not have the hard statistics, 
this seems to be about the same as the last two or three spring 
symposia. 

There were the usual 5 or 6 1st time attendees at the Roadmap. 

The RT-11 SIG put on 27 session hours, of which 6 hours had 
some kind of change due to speaker cancellations. Actually, 
a total of 7 hours changed, but one replacement speaker 
cancelled. Thanks are due to Greg Adams, Rally Barnard and 
Bill Walker for filling in with solid hour talks. Special 
thanks to Adam Bridge for filling in for 3 hours, including 
one when he was clearly not feeling well. On the whole, the 
RT part of the symposium seemed to go fairly well, although 
there was a definite lack of audience participation. There 
were relatively few audience questions at most of the sessions, 
and the sessions that are driven by the audience were flat. 

With the exception of the "Application Workshop", most of these 
were not very useful. Of course this is partly a function of 
the maturity of the RT-11 products, but I think that it was 
also a reflection of the overall symposium. The audience at a 
number of the non-RT sessions I went to also lacked spark. 
Several other Symposia Committee members also felt that we had 
a very compliant audience this time. 

The most important subject (for RT-11) was DECnet/RT, which is 
comming soon (maybe this calender year). The most popular RT-11 
session (apparently) was a session discussing the use of RT-11 
on the Goodyear Airships. 
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LOOKING FOR A LITTLE TeX 
and 

Other Idle Thoughts 


TEX 

John Bullock's request in the January 1988 Minitasker for an RT 
implemenation of TeX caught my attention. Like Shal Farley 
(March 1988 Mini tasker ) , I too have looked for an RT-11 version 
of TeX. I haven't had any success in finding it, but I'll add 
my comments anyway. 

The TeX Users Group Membership List includes a list of computers 
on which TeX is currently running. PDP-11 is not on the list 
for any of the operating system; however, PDP-11 does show up 
in the listing of members by computer. Thus there are members 
of TUG who have PDP-11's, but are they running TeX on the 11? 
Darned if I know. A little over a year ago I wrote to several 
of those people asking if they had TeX running on a PDP-11 and 
if so where could I get information on it. I had two replies. 
One person said that TeX was written in Pascal so all one needed 
was a Pascal compiler and a linker. Since that didn't really 
answer the question "Do you have it running on a PDP-11?", I 
never followed it up. Perhaps I should have. The other reply 
was from a person who said that he was a member of TUG as an 
interested observer rather than an actual user. He didn't know 
of any PDP-11 implementations. He allowed that the 64kb 
addressing limit would be a major stumbling block. 

I have also asked around at more than one DECUS Symposium, but 
with no better results than Shal reported in his letter. I 
agree with Shal in that it appears that if you want TeX on a 
single user system, then you'd best get a MS-DOS machine, a 
Macintosh, or maybe even an Amiga. (Since the MS-DOS and 
Macintosh implementations are commercial products, TeX is 
actually cheaper for a VAX than for a PC! That doesn't happen 
often.) 

Shal mentioned two possible ways to port TeX to another machine: 
1) port TANGLE and hence the whole WEB system in which TeX is 
written, or 2) port the the Pascal code generated by TANGLE. 
There may be a third method - start with one of the 
implementations of TeX in C. The article "TurboTeX: A New Port 
in C for Unix and MS-DOS" by Richard Kinch and Jennifer 
Vollbrecht in the April 1988 issue of the TUGboat (the TeX Users 
Group newsletter) describes one such conversion of TeX to C. In 
fact the methods they describe may be of more use than the 
actual result - particularly if a program exists to translate 
Pascal to Modula-2. 
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WEB 


As Shal noted, TeX is written in WEB. The intent of WEB is not 
only portability, but also good documention. The WEB source 
file is supposed to contain the source code and the documention. 
If the WEB source file is processed by the program TANGLE, the 
result is a Pascal source file which is then compiled and linked 
like any other Pascal program. On the other hand if the WEB 
source file is processed by the program WEAVE, the result is a 
TeX source file containing the documentation. 

The input to TANGLE can include an optional change file which 
modifies the main input file. The idea is to have the main WEB 
source a sort of generic source file - more or less good for all 
systems. Then you supply a change file which TANGLE then uses 
to tailor the generic source file to the particular system. 
Likewise WEAVE processes the generic file and the change file to 
produce documentation for the specific version of the program - 
the changes are even marked in the documentation. 

According to the documention for TANGLE, TANGLE holds all of the 
Pascal text in memory. For a large program like TeX, this means 
that TANGLE needs large amounts of memory. 

Although WEB, as implemented by Knuth, creates a PASCAL program, 
there is really no reason why the same sort of scheme for 
combining source code and documentation couldn't be applied to 
other languages as well. In fact there are C versions of WEB. 
(The C implementations of TeX do not use CWEB.) The WEB system 
has also been adapted to Modula-2. See the October 1986 and 
April 1987 issues of the TUGboat for information on CWEB, and 
the July 1987 issue for information on MWEB. 


Previewer for TeX 

There is is a previewer for TeX DVI files which is written in 
Modula. It is described in an article in the March 1986 issue 
of the TUGboat . Obviously for best results you need a graphics 
terminal. The program was written using a VAX/VMS Modula-2 
compiler from the Univerity of Hamburg. It would be interesting 
to know if this program would work using the Modula-2 compiler 
for RT from ModulaWare, GmbH that John mentioned in his letter 
in the January 1988 Mini tasker . Of course even if it does work, 
it isn't all that useful if you have to use a different machine 
to generate the DVI files in the first place. 


Older Software 

It may be a strange combination of old and new, but has anyone 
else tried to run Saturn Calc Version 2.3F on RTll V5.4C (SJ 
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monitor)? I'm having trouble with it corrupting spreadsheets 
when writing to a logical subdevice. Is this a problem with 
Saturn Calc? The LD handler? All of the above? None of the 
above? It worked ok with RTll V5.4A. 


Faster Modems 

Several companies (e.g. U.S. Robotics) now have 9600bps modems 
for use on dial up lines. Actually they are 9600bps in one 
direction and 300bps in the other. (The big print giveth and 
the little print taketh away.) I have read that if you are 
transfering files using Kermit, you are better off to set the 
modem for 2400bps. The claim is that the Kermit protocol, with 
its small packet size, does not lend itself well to the 
situation where transmit and receive speeds are vastly 
different. Since the VTCOM - TRANSF combination uses a longer 
packet size, at least to start, perhaps it gives better results 
with this type of modem. Has anyone tried it? If so, what kind 
of net transfer rates do you get? 


SIG Newsletters 

While there are those that don't like the combined newsletters, 
I for one like it. I think it is the best value since they 
started charging for the subscription service. Of course I turn 
to the RT section first, but I usually skip through most of the 
others as well. Sometimes I even find something useful in one 
of the others. 

I have also heard that there has been consideration of forcing 
all newletters to use a common format. Indeed in May 1987 a few 
of the newletters began to use a common format. These are the 
newsletters at the beginning of the "The Big One" and whose 
names are shaded in the table of contents on the front cover. 
As I recall the consistant format was supposed to make 
everything more readable and also increase the number of 
subscriptions. As far as I'm concerned the format of the 
"shady" newletters is neither easier nor more difficult to read 
than the others. (In fact the "easier to read" format has lines 
longer than were recommended in an article in Digital's 
Desktopics publication.) Certainly I can't imagine that if all 
the SIG's used the same format, the number of subscribers to the 
Newsletters would suddenly increase. 

There is a change in the Newletters I would like, though. Put 
the expiration date on the mailing label. As it is, the mailing 
label has your Decus number and the date your order was 
processed. It's interesting to know when they processed your 
order, but when I look at the label I'd rather know when the 
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subscription runs out than when I paid for it. Is really all 
that hard to put the expiration date on the label? 


After RT 

Both John and Shal mentioned another topic of interest to me. 
It's what I have called "If not RT, then what?". 

I'm one of those "small users" that John mentioned in his letter 
- someone who wants a "simple, uncomplicated, development and 
applications environment combined on the same hardware". Indeed 
an LSI-11 based system running RT-11 has provided just such an 
environment, but there are times it sure would be nice not to 
have the 16 bit address limitation. (Implementing TeX is an 
example.) So if I want to upgrade my system, what are the 
choices. I have thought of several. 

VAX/VMS? No - too expensive. If the hardware costs don't get 
me, the software costs most certainly will. Last fall in 
Anaheim Ned Rhodes gave a talk comparing TSX and VMS. As I 
recall the software costs for the VAX were about 3 times that of 
the PDP. Of course he was talking a multi user system, but 
presumeably the ratio would be more or less the same for a 
single user system. 

A newer PDP-11? Maybe. My system is far from the latest and 
greatest, so I can still increase perfomance simply by changing 
processor boards and adding some memory. I'd still have good 
old RT, but the addressing limitations remain. From a hardware 
standpoint this is probably the cheapest upgrade. Although the 
software will be less than for a VAX, it's still going to be 
more than for a PC. 

An 80386 or 68020 based system? Which one? What operating 
system? 

VAX/RT? Would be nice, but it would have to be priced 
competively with 80386 and 68020 systems. As Shal pointed out, 
that is the rub. Can DEC or any one else sell enough to get 
back the development costs? Sad to say I'm afraid this is a 
case of Digital doesn't have it now, and it's too late to get 
it. 

I'm sure there are plenty of opinions out there on the ideal 
single user system. I'd be interested in reading them, and Jack 
Crowell is usually looking for something to print. 


Scott B. 
21084 N. 
Kildeer, 


Harrod 

Middleton Dr. 
Illinois 60047 
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April 27, 1988 


Mr. John M. Crowell 
RT-11 Newsletter Editor 
Multiware, Inc. 

2121-B Second St. Suite 107 
Davis, CA 95616 

Subject: SCURT LUG Meeting Schedule 

Dear Jack: 

The SCURT (Southern California Users of RT-11) LUG holds regular meetings on 
the forth tuesday, 9:00 am, on the CalTec campus (Room 151 Arms) in Pasadena, 
California. Below is a list this year's scheduled topics. For a location map 
or to be put onto the mailing list, please call Gary Sallee or Shal Farley. 

SCURT is looking for meeting speakers and topics. If anyone is interested in 
speaking or has a topic suggestion, please call Gary or Shal. 

Sincerely, 


Gary F. Sallee 


Southern California Users of RT-11 
Digital Equipment Users Society 

June 28, 1988: Hardware for Network Wiring Systems 

July 26, 1988: Interface and Formats of High Capacity Tapes 

August 23, 1988: The Design of a 5th Generation Continuous UPS 

September 27, 1988: The 11/73 in VME Real Time Acquisition 

October 25, 1988: Digital's Networking and Compilers for RT-11 

November 22, 1988: The Transition to Programing in a 4GL 

December 20, 1988: RTll (TSX+) Hints, Kinks and Magic 

January 24, 1989: RTll Graphics & Desktop Publishing 


************************************************************** 


Chairman: 

Shal Farley 

(818) 

351-5493 

Program Chairman: 

Gary Sallee 

(714) 

970-2864 

Membership Chairman: 

Greg Adams 

(818) 

980-6622 

Tape Librarian: 

Shal Farley 

(818) 

351-5493 

Landlord: 

Jonathon D. Melvin 

(213) 

202-1081 

DEC Rep.: 

Rich Milligan 

(213) 

417-4454 
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Kermit/RT/TSX Introduction 
Gary F. Sallee 

From Brian Nelson's K11ART.DOC, K11F85.DOC, and KllINS.DOC 
Presented at the Regular SCURT LUG Meeting 
Southern California Users Of RT-11 
Pasadena, California 

ABSTRACT 

This is an introduction to Brian Nelson's KERMIT from the 
University of Toledo as it may be used in an RT-11 or TSX-plus 
computer system. Topics covered will be what Kermit does, how I 
use Kermit, what SYSGEN options are needed, how to set up the 
needed hardware, how to install Kermit, how Kermit talks to 
other Kermits, how to use KERMIT.INI, how to set up a dialing 
list, and anticipated futures by Toledo and by SCURT. 

PART 2 

(See June, 1988 Newsletter for Part 1.) 


THE KERMIT PROTOCOL 

The Kermit protocol is designed to operate over normal 
asynchronous terminal lines. All data and commands are 
transferred with a packet oriented protocol, basically 
consisting of a start of packet character (normally SOH), 
followed by length, control, data and check sum fields. 
Communications is half duplex. So for every packet sent, the 
sender must wait for either an acknowledgement packet (ACK) or a 
negative acknowledgement packet (NAK). Transmission is in 
ASCII, with no requirements needed for the transmission of eight 
bit characters or control characters other than the choice of 
control-A for marking the start of a packet. All "control" 
characters imbedded in the data are prefixed to convert them to 
printable characters. The same applies to eight bit characters 
if required by the characteristics of the line. 

Since there are many different implementations of Kermit, the 
protocol provides a mechanism by which the capabilities of two 
connected Kermits can be negotiated to allow for differences in 
the level of protocol support. Examples of optional protocol 
features include data compression and transfer of file 
attributes. 

TRANSMISSION OF FILE ATTRIBUTES 

One of the things that two Kermits exchange before any file 
transfer is an information packet, this packet tells the 
receiving Kermit about itself. The last field in this packet, 
the "CAPAS" mask, tells Kermit if the other one can process 
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attribute packets. If two Kermit-11's are communicating, they 
will find that each can do so, and the sender of a file will 
then send over attribute packets indicating the need (or lack 
of) for binary transmission, based on the file organization, 
file type and protection code (for RSTS/E). 

One of the optional features of the Kermit protocol is the 
ATTRIBUTE packet. The attribute packets allow a Kermit program 
to send to a receiving Kermit information regarding the file 
organization, size, cluster/retrieval size, protection and so 
forth. There is even a system dependent attribute packet type 
that can be used to transfer things like the RMS11 IFAB (the 
RMS/FCS attributes). 

If the sending Kermit-11 is running on RSTS/E, RSX11M/M+ or P/OS 
it will also send a copy of the RMS/FCS attributes so the 
received file will be identical (to FCS and/or RMS) to the copy 
on the sender's system. Since other implementations of Kermit 
may use this special system attribute packet, Kermit-11 always 
sends an attribute packet telling the receiver what hardware and 
operating system it is running on, and thus will only use such 
data if they are compatible. Of course, there will be times 
when a file may be binary and Kermit-11 can't tell so, many 
Kermit's have a SET FILE BINARY and SET FILE ASCII to allow the 
user to override defaults. Kermit-11 also has a SET FILE 
AUTO/NOAUTO to disable it from trying to determine a file's 
binary status. 

HOW KERMIT TRANSFERS A FILE 

The means by which Kermit transfers a file is quite simple; the 
protocol includes a START OF HEADER (normally a SOH, control A), 
after which follows a LENGTH field, then a SEQUENCE character 
and a TYPE field. After this, the DATA follows, with a check 
sum trailing the data segment. The check sum can be one of 
three types; 1) basically an additive sum wrapped into 6 bits, 

2) the same but 12 bits in size, and 3) a CRC based check sum. 
The sequence number increments for each packet sent, module 64. 

The packet format is: 


H-1-1-1-1--1-f 

| MARK I char(LEN) | char(SEQ) I TYPE | DATA | CHECK | 

+-+ - +-+-+-+-+ 

where all fields consist of ASCII characters, and the char 
function converts a number in the range 0-94(10) to a printable 
ASCII character by adding 32(10). The MARK, LEN, SEQ and TYPE 
fields are one byte, the data field is variable in size, and the 
CHECK field is one to three bytes in size. 

The MARK (normally control A) signifies the start of a packet. 
The length field tells how long the rest of the packet is. The 
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SEQ field is used to insure synchronization used to detect lost 
or duplicate packets. The SEQ number wraps around every 64 
packets due to the need to encode it as a printable ascii 
character in the range 32 (10) to 126 (10). The TYPE field 
specifies whether the packet is a DATA or CONTROL packet. The 
DATA section is used for the actual transfer of data or 
informative messages from a Kermit server, this field can be up 
to 90 characters in length. Any character whose low seven bits 
fall in the range of 0 to 37 (8), i.e., char and 177 (8) is less 
than 40 (8), will have the value 100 (8) exclusive or'ed 
(xor'ed) with itself and be prefixed by a shift character, " 
Other shift characters may be use for eight bit characters i7 
the line characteristics require such. Data compression may 
also occur in the data field, this is done with yet another 
shift code and byte count sequence. The CHECK field is a check 
sum, either a one character, two character or three character 
CRC check; the sender computes it and the receiver must compute 
it and compare. A check sum mismatch will result in the 
receiver sending a NAK packet (negative acknowledgment) which 
directs the sender to resend the NAK'ed packet. The packet may 
be followed by a terminator (likely an ASCII 13). This 
terminator is NOT part of the protocol and is sent only to tell 
the receiver that a "line" is present. Not all Kermit 
implementations require this; all Kermits will discard data 
outside of a packet in any event. 

Error detection and recovery is by check sum, as noted, and by 
packet read time outs. If the packet should be corrupted the 
check sum will be incorrect, the receiver will NAK the packet. 

If an expected packet never arrives within the timeout period, 
or if the received packet is not the expected one (as determined 
by the SEQ field) the packet will also be NAK'ed. There are 
limits as to how many times an expected packet will be NAK'ed 
without aborting the current operation. The retry limit can be 
changed with a SET RETRY n command. 

PACKET TYPES 


D Data 

Y Acknowledgement (ACK), text may be in DATA field 
N Negative Acknowledgement (NAK) 

S Send initiate (Send-Init) 

R Receive Initiate 

B Break (EOT, end of transmission) 

F File name header 

Z End of file (EOF, end of current file) 

E Error packet, text may be present in DATA field 

G Generic SERVER command. The first character in the data 
field will be a command to a server, arguments may follow 
that character. 

I Login, user and password follow in data field 
C CWD, change working or default directory. 
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L Bye, Logout server 

F Finish, Exit server, but do not log out 
E Erase, delete files on server system 
D Directory query 
U Disk space usage query 
T Type a file onto local kermit 
R Rename file(s) on server system 
K Copy file(s) on server system 

W Who's logged in, as in show sys, sy/s, dev tt 
M Send a terminal message to a user 

H Help, the server responds with commands it can do 
Q Server status query 
P Program, run a program 
J Journal 

V Variable, alter a Kermit setting 

C Execute host command. The host command follows in the 
data field. 

Note that some of the generic server commands, as well as the C 
packet (CWD), may not be feasible for a given environment. For 
instance, the REMOTE LOGIN command, which sends the generic I 
command to the server, can only be done under RSTS/E; the 
generic U command (disk space) is meaningless under RSX unless 
one wants the free space on the entire volume. No Kermit server 
will abort on receiving a packet it can't execute, it will 
simply send an error packet with an informative message saying 
it can't process the requested function. 

A TYPICAL TRANSACTION 

An example of a Kermit-11 kermit telling a VMS Kermit-32 server 


to 

expect a 

file follows. The Kermit-ll command was SEND 

JUNK.TST. 




(0)PDP 

sends: 

A. S~* <a-#Y3~( , 


(0)VAX 

sends: 

A, Yp/ @-#Y3~! 


(1)PDP 

sends: 

A-!FJUNK.TST,-4 


(1)VAX 

sends: 

A%1Y,i 


(2)PDP 

sends: 

A’"D$ set ter/vtlOO#M#J$ xcc :== ccl cc 
#M#J$ xas :== ccl as#M#J!4S 


(2)VAX 

sends: 

A%"Y.5I 


(3)PDP 

sends: 

A%#Z,X" 


(3)VAX 

sends: 

A%#Y/R9 


(4)PDP 

sends: 

A%$B! # 


(4)VAX 

sends: 

A%$Y+X 

In 

packet number 7ie 

ro, the Kermit's exchanged information 


regarding their capabilities. The PDP-11 sent an "S" packet 
with the data for its maximum packet length, default time out, 
number of pad characters to follow a packet (none, hence the 
space), use a null for padding, end of line terminator (a <CR> + 
32), the prefix character for control characters, a "YES" to say 
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the it can prefix eight bit characters with the default, that it 
would like to use CRC block checks, that it will use a tilde for 
data compression, and the "CAPAS" mask, which here says that it 
can process attribute packets (discussed later). Since the VAX 
also sends a "3" for the check sum type, they will both switch 
to CRC checks on the following packets. In packet 1, the PDPll 
sends the filename the VAX should use for the file it creates. 
The VAX then sends the acknowledgement. In packet three, the 
PDP sends the first (and only for this file) packet of data. 

Note that the sequence is a carriage return line feed 

sequence with 100 (8) xor'ed into each character. The "_#" 
character informs the other Kermit that it must xor the next 
character with 100 (8). In packet three the PDPll sends an EOF 
packet, the VAX acks it. In packet four, the PDP sends a break 
packet which tell the VAX that no more files (of a possibly 
wildcard group) are coming and the VAX Kermit acks the break 
packet. Both Kermits now switch to the single character check 
sum and the VMS kermit enters the server idle state. 

More specific information regarding Kermit packets and state 
transitions can be found in the references listed at the end of 
the article. 


THE PDP-11 KERMIT-11 IMPLEMENTATION 

The Brian Nelson (Toledo) version of Kermit-11 is written in 
Macro-11 and can assemble and run on RSTS/E, RSXllM, RSXllM 
Plus, P/OS, TSX-plus and RTll. The RSTS and RSX file system 
interface is via RMSll version 2, while the RTll interface 
attempts to emulate the RMSll subsystem. The choice of Macro-11 
for the implementation language was made for several reasons, 
one being the availability of the assembler on all systems and 
another being speed and compactness of the code. 

RMSll was used for RSTS/E and RSX to provide a common I/O 
interface to the host file system. Additionally, Bob Denny of 
Alisa Systems further extended the RMS interface to support 
remote file access over DECNET with Kermit, allowing commands 
such as SEND NODENAME::[BRIAN.FUBAR]FILE.TYPE and other remote 
file accesses over DECNET. RMSll version 2 also provides a very 
simple and powerful means of doing wildcard searching, file 
renames and file deletion via the $PARSE, $SEARCH, $RENAME and 
$DELETE macros. 

Points against RMS basically amount to it's size, RMS is quite 
large even if overlayed. This is helped by using the segmented 
PMSRER available on RSTS/E and RSXllM Plus, though there is no 
,,.,,,,.1 fiio arress for RMSRES in the current release of 
i' o i m > | II. The olhci objection to RHS will come fiom RSTS/E 
users, who are used to using files that normally lack file 
attributes. This is overcome by the ability of RMS V2 to create 
stream ascii files. 
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The RSXl1M/M+ and P/OS versions of Kermit-11, like the RSTS/E 
and RT versions, receive eight bit data assuming no parity is 
used. Where parity is a must, Kermit-11 has to use a prefixing 
scheme for eight bit binary data. Like the RSTS/E version, 
binary files are created as FIXED no carriage control files such 
as used for task images. Note that parity generation is done by 
software in Kermit-11. The P/OS version runs under control of 
DCL. Support for the PRO TMS (Telephone Management System) 
option is now included. 

The RTl1 and TSX-plus version of Kermit-11 maintains source 
module compatibility with the RSTS/E and RSX versions. Each 
version of Kermit-11 has it's own source file to deal with the 
operating system, for RSX it is K11M41.MAC, for RSTS/E they are 
K11E80.MAC and K1180S.MAC, and for RTll they are called 
Kl1RT*.MAC. Apart from these specific files, all other source 
files are shared. The RTll Kermit-11 can use either the version 
5.x XL and XC handler for high throughput, or it can use 
multiple terminal service to do all it's terminal I/O. This 
second option allows the use of any interface supported, 
including the PDT150 modem port, DL/DLVll's and DZ/DZVll's. The 
drawback is overhead, the RTll MT service can't sustain a rate 
much past 1200 baud at most. This is not a problem for Kermit, 
however, due to it's half duplex nature and the fact that no 
packet received is ever longer than the ring buffer size. The 
only problem is in when Kermit-11 is running as a terminal 
emulator (the Kermit CONNECT command) where the data coming from 
the remote host can easily overrun the executive's buffer. A 
SET RTll [NO]FLOW command was added to force Kermit-11 to send 
its own flow control to the host via XON and XOFF. TSX-plus 
users can connect to CL: for dialing out, the exact means is 
documented in the Kermit-11 users guide. The disk i/o emulates 
the RSTS/E and RSX RMSll version, and each executive directive 
has its error codes mapped into an unique global error code, 
with the symbolic names corresponding to the nearest RMSll error 
name. Wild carding is handled, of course, by non 
file-structured access to the directory on the desired volume, 
and supports full RTll wild card file names. 

FUTURE DIRECTIONS 

SCURT Additions: 

CREATE FILE NAME, by Shal Farley. 

Automatic SET SPEED when the modem connects, by Gary Sallee. 

These two additions are working in house and need to be 
integrated, by maybe January 1988. 

Toledo Additions: 

With the advent of packet switched networks and satellite 
communications the Kermit protocol will likely be extended to 
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increase efficiency over such links. The main problem is the 
half duplex nature of Kermit. The half duplex packet 
acknowledgments can take up to several seconds in transit thus 
drastically reduce the throughput. There are several new 
possibilities under discussion. 

REFERENCE MATERIAL 

The above describes only the PDP-11 Kermit-11 implementation. 
For further reading please see: 

"Kermit: A File-transfer Protocol for Universities" 

Frank da Cruz and Bill Catchings 
BYTE Magazine, June/July 1984 

"The Kermit Protocol Manual, version 5" 

Frank da Cruz April 1984 

Columbia University Center for Computing Activities 

INFORMATION ON OBTAINING KERMIT 

KERMIT Distribution 

Columbia University Center for Computing Activities 
7th Floor, Watson Laboratory 
612 West 115th Street 
New York, N.Y. 10025 

Kermit is also usually found on the Decus symposium SIG tapes. 
Kermit-11 is available from DECUS as number 11-731 

WISH LIST 

1. Allow device DOC: or DK: for KERMIT.INI. 

2. Program TRANSFER to use SET PAUSE and XON, XOFF. Pause at a 
<CR><LF> or at 63 characters, which ever comes first. 

3. Send file protection status for RT-11 and TSX-plus. 

4. Add WHO for TSX-plus. 

5. Add hooks to allow external processing of data or commands. 

5.1. Allow command files to run through CONNECT mode. 

5.2. Allow custom data compression and expansion. 

5.3. Allow custom data encryption and decryption. 

5.4. Allow server for X-Window. 

5.5. Allow directory tree search through devices and logical 
devices. 
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5.6. Allow entire custom user interface, with Kermit file 
transfer. 

5.7. Allow entire custom file transfer, with Kermit-11 user 
interface. 


Digital hardware that Kermit is currently available for: 


Operating Program 


Machine 

System 

Language 

Contributor 

DEC 

PDP-11 

MUMPS-11 

MUMPS-1982 

Cornell U 

DEC 

PDP-11 

RSTS/E 

Macro-11 

U of Toledo 

DEC 

PDP-11 

RSX-ll/M 

Macro-11 

U of Toledo 

DEC 

PDP-11 

RSX-11/M+ 

Macro-11 

U of Toledo 

DEC 

PDP-11 

RT-11 

Macro-11 

U of Toledo 

DEC 

PDP-11 

RT-11 

OMSI Pascal 

U of Toronto 

DEC 

PDP-11 

TSX—plus 

Macro-11 

U of Toledo 

DEC 

PDP-11 

Unix 2xBSD 

C 

Columbia U 

DEC 

PDP-11, ... 

Unix V7 

C 

Columbia U 

DEC 

PDP-8 

OS8, RTS8 

PAL-8 

R. Hippe 

DEC 

Pro-3xx 

P/OS 

Bliss, Macro 

Stevens I.T. 

DEC 

Pro-3xx 

P/OS 

Macro-11 

U of Toledo 

DEC 

Pro-3xx 

Pro/RT 

Macro-11 

U of Toledo 

DEC 

Pro-3xx 

Venix VI 

C 

Columbia U 

DEC 

Pro-3xx 

Venix V2 

C 

Columbia U 

DEC 

Rainbow 

CPM86 

ASM86 

Columbia U 

DEC 

Rainbow 

MS-DOS 

MASM 

Columbia U 

DEC 

Rainbow 

QNX 1.x 

C 

Merrell-Dow 

DEC 

VAX 

Ultrix-32 

C 

Columbia U 

DEC 

VAX 

VMS 

Bliss,Macro 

Stevens I.T. 

DEC 

VAX 

VMS 

C (VAX-11 C) 

Columbia U 

DEC 

VAX 

VMS 

Pascal 

U of Toronto 

DEC 

VAX, ... 

Unix 4xBSD 

c 

Columbia U 

DEC 

VT-180 Robin 

CPM80 

Turbo Pascal 

Jeff Duncan 

DEC 

VT-180 Robin 

CPM80 2.2 

M80,LASM 

ACC 

DECmate-II,III 

CPM80 2.2 

M8 0,LASM 

ACC 

DECsystem-10 

TOPS-10 

Bliss, Macro 

Stevens I.T. 

DECsystem-20 

TOPS-20 

MACRO-20 

Columbia U. 
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LW Handler for Apple LaserWriter 
John M. Crowell 


By the time this appears in print, I should have finished (as much as I finish 
anything) my LW handler for the Apple LaserWriter. Before I send it to the 
DECUS Library, however, I'd like to have it shaken down by as many people 
as possible. 


Basically, it is a serial line printer handler that translates text into Postscript 
or allows postscript programs to pass through unaltered. Font seletion, size, 
margins, page sizes, etc. are settable by escape sequences and defaults are 
SET-able. 


This handler should work for just about any Postscript device including the 
LaserWriter, and DEC'S Scriptprinter. I'll be using it on a PRO-350, but it'll 
work with normal DL-type serial ports too. 


If you have a Postscript device on the end of a serial line and would like to field 
test this handler (and send me a report on how well it performs or how badly it 
doesn't), drop me a line (and a blank floppy) and I'll send you a copy. 


John M. Crowell 
Multi ware, Inc. 

2121-B Second St. #107 
Davis, CA 95616 

I guess I should say the usual words about LaserWriter being a trademark of Apple Computer, and 
Postscript probably belongs to Adobe. 
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LETTER FROM THE EDITOR 

Welcome to the July issue of the Site, 

Management, and Training SIG Newsletter. 

This month we have a very interesting article on 
power available in the United States from Bruce 
Barton. 

Next month look for details on new working groups 
formed at the Spring 88 Symposium in Cincinnati. 
Submissions should be sent to: 

Gregory N. Brooks 
Washington University 
School of Medicine 
Department of Pediatrics 
400 South Kingshighway 
St. Louis, MO. 63110 
(314) 454 2237 

I can accept VMS backup tapes, tar format tapes, 
WPS Plus documents, Mass 11 documents, IBM PC 
5 1/4 (low and high density) floppies (Word Perfect, 
Microsoft Word, Mass 11, or WPS), and of course 
good old Runoff source. 

I’m rather new to BITNET but you can send me 
mail or submissions via BITNET to: 
BROOKS_G@WUMS 

Look forward to new submissions and/or comments 
from our readers. 

Greg Brooks 

THE RA60 AND THE ART 
OF AVOIDING 220 VOLT 
POWER ALL ABOUT AC 
POWER 

By Barton Bruce, Cambridge 
Computer Associates 

Editor’s note: The following was extracted from the 
Pageswapper VAXnotes system for publication. 

In reading all the above (previous VAXnote 
messages concerning RA60 power) it is clear there 
is a considerable amount of confusion about the 


power generally available in the US. It is really not 
terribly complicated. There are always exceptions 
and weird things that have interesting histories, but 
most power you will find near your computer room 
falls into a few simple categories. Read on and I will 
either clear up a few things for you or totally con¬ 
fuse you. 

Lets start with single phase ’house’ or small office 
power. The immediate source is a single phase 
distribution transformer generally with a single 
center-tapped secondary winding. The centertap is 
grounded, and is referred to as the ’neutral’, or 
’grounded current carrying conductor’ or, especially 
in reference to color coding, the ’identified’ conduc¬ 
tor. This neutral is electrically half way between the 
ends. The voltage we normally get in such service 
ranges from 220 to 250 across the two ends (or 
’hot’ wires), and obviously is 110 to 125 from either 
hot leg to the neutral. If you have ever wondered 
why some devices carry a nominal 117 volt rating, 
just average 110 and 125. If this is hard to visual¬ 
ize, let us draw a simple analogy. A flashlight cell is 
generally about 1.5 volts (actually 1.54 for a plain 
zinc-carbon cell). The two cells stacked in a 
flashlight have 3 volts from end to end, and 1.5 
from the center connection to either end. Note, 
though that the center connection would be (-) in re¬ 
lation to one end and ( + ) to the other. 

For house power it is desirable to have the voltage 
to ground be as low as possible from any ’hot’ wire, 
and yet have as high a voltage available where work 
needs to be done so the least amps will do the job. 
With the center point grounded, people are only ex¬ 
posed to a nominal 120 volts to ground, but 240 is 
available to do the work at one half the amps that 
would be needed at 120 volts. One half the amps 
needs one half the wire size, etc... Another nice 
benefit is that a 3 wire circuit carrying the 2 hot 
legs and the neutral can be broken down to serve 2 
sets of 120 volt loads which if wired separately 
would need 2 wires each, or 4 wires. When fed to¬ 
gether, the neutral carries only the difference, and 
not the sum of the two 120 volt loads fed from op¬ 
posite hot legs. If the 120 volt loads are both ex¬ 
actly equal, there is NO current in the common 
neutral wire. Three phase power gets a little more 
complicated, but is still easy to understand. If you 
imagine a generator with 3 separate windings each 
physically arranged 120 degrees from each other 
such that the sine wave of the alternating current 
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in each winding looks exactly the same, but is 
phase shifted 120 degrees from the next winding, 
you have a good starting point to understand how it 
all works. Each of those windings could be kept 
separate, and each wired to the corresponding 3 
similar and separate windings of a motor. The con¬ 
nection between generator and motor would require 
6 separate wires - 2 each for the 3 separate wind¬ 
ings in each machine. As the generator rotated, the 
magnetic fields in the motor’s 3 windings would 
change in the same rotary sequence that the cor¬ 
responding windings have current induced in them 
by their relative motion to a magnetic field. This ro¬ 
tating magnetic field is what makes 3 phase motors 
so nice. They really want to turn. A single phase 
motor would really prefer to just sit and hum and 
get hot if some extra tricks weren’t played to coax 
it to spin. 

Now let’s look at those 3 separate windings, each 
with 2 wires. There is no need to keep them all 
separate. There are 2 standard ways to interconnect 
them. 

If 1 wire from each winding were to be connected 
together to make a common point and that point 
were to be grounded and labeled ’neutral’, and the 3 
remaining wires were diagrammed as points on a 3 
pointed star radiating out from the common center 
(and labeled ’hot’ or ’phase’ legs/wires), you would 
have what is called a STAR or WYE connected 3 
phase 4 wire circuit. If, rather than running a 
motor, each hot wire were to be used separately for 
a single phase connection between itself and the 
common centerpoint neutral, and if each of our 
windings were 120 volts, we could power 3 separate 
120 volt circuits and the common neutral would 
carry ONLY the unbalanced current if the 3 loads 
were not equal. 

This is almost that same as our single phase 
neutral that only carried the difference, but here we 
have a 120 degree phase relationship, so it is not 
quite so simple. The maximum the neutral would 
carry is what any 1 phase leg carried when the 
other 2 had NO current flow. The minimum is no 
amps at all if all three phase legs are equally 
loaded. This is great because we get the work of 3 
separate 2 wire circuits using only 4 wires, and like 
our 120/240 single phase example we have not only 
a maximum of 120 volts to ground, but have a 
higher voltage between phase legs to deliver more 
power at less amps to loads that are designed for it. 


BUT, we do not quite get 240 volts. In our star, 
each winding was 120 volts, but also had its sine 
wave 120 degrees shifted from either other winding, 
so 2 windings that seem to be connected end to end 
via the common (grounded neutral) center point 
don’t have their end points apart by the simple sum 
of their voltage the way our 2 flashlight cells did. If 
you think of 3 sine waves graphed on top of each 
other 120 degrees apart (each peaks l/3rd of a full 
cycle later than its predecessor) it should be clear 
that no 2 reach full voltage at the same time. The 
actual voltage between any 2 hot legs is the the 
square root of 3 (1.7326...) times the hot leg to 
neutral in a star connected circuit. 208 volts is 
1.7326 times 120. That is where the common 208Y/ 
120 volt power comes from. Another very popular 
combination is 480Y/277 volt power, but more of 
that later. 

The other common connection is DELTA. Simply 
connect our 3 separate windings together to form a 
triangle - each of the 2 ends of any winding con¬ 
nects to a different other winding. The voltage be¬ 
tween these corners may be any of several popular 
voltages ranging from 240 to 440 or 480 or 550 or 
even 600. Common electrical wire is rated up to 600 
volts. Beyond this ’barrier’ is another world of 
higher voltage power distribution, and is not what 
we are talking about here. 

Basic DELTA power has no neutral halfway point 
and may not have any connection to ground at all! 
No-ground lets the whole circuit ’float’ above ground 
at any voltage it wants, much as you do as you 
shuffle across a rug in winter getting a static 
charge thousands of volts away from whatever you 
zap when you get close. In the floating DELTA cir¬ 
cuit it may be some weak piece of insulation that 
can hack the nominal voltage but not the static 
voltage that gets zapped. To eliminate this, some 
part of a DELTA circuit may be grounded. It might 
be a corner. If the circuit voltage were 240 volts, 
the curious programmer trying to connect his com¬ 
puter would find the following confusing state of af¬ 
fairs. There would be 240 volts between any 2 of 
the wires, and to ground 0 volts from 1 wire and 
240 volts from the other 2. 

This is not exactly like home power, and where is 
the 120? Obviously there isn't any. But if this were 
in a small factory that needed a bit of 120 volt 
power, but certainly was too small to need any 
extra transformers, another trick is pulled. If a 
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center-tap in the middle of one of the sides of just 
one of the windings were to be grounded instead of 
a corner, and wired as the neutral with the 2 ends 
of that winding being our 2 hot legs, we get vanilla 
that is exactly like what we get at home. 
EXACTLY. But, in that factory we still have that 
3rd corner of the DELTA triangle. Don’t even 
dream of connecting between this guy and the 
grounded neutral on the far side (it is actually 208 
volts to ground in this example). Just as the NEC 
(National Electric Code) makes a issue of having 
the GROUNDED CURRENT CARRYING 
CONDUCTOR ’Neutral’ colored white or light gray 
(as opposed to the frame bonding safety ground, col¬ 
ored ’green’), it also REQUIRES this 3rd corner of 
a DELTA wired this way to be ORANGE or other¬ 
wise distinctly flagged (at any point where a connec¬ 
tion could be made and the neutral is present - i.e. 
in any box or cabinet, but not the whole length of 
the wire in a pipe) to identify it as the ’WILD 
Phase’ so no one ever uses it with the neutral. See 
NEC 215-8. 

If you have a true floating DELTA, it is possible to 
derive a central, groundable midpoint using only 3 
auto-transformers (single winding inductors - no 
separate primary/secondary windings) wired star 
connected. You get 240Y/139 volt power (yuk). If 
each auto-transformer had a partial winding tap, 
you could get 125 volts to your new midpoint and, 
yes, between these taps there would be 208 (i.e. 
regular 208Y/120). For this configuration the NEC 
requires the autotransformer full winding be able to 
carry the potential full unbalanced (3 phase legs not 
equally loaded) current to the neutral wire. The va¬ 
nilla ’boost/buck’ autotransformer is NOT so 
constructed, so a special one is required. 

There is a Delta that is actually only 2 delta con¬ 
nected windings with the 3rd simply left out! It is 
call aptly ’Open Delta’, and for many purposes be¬ 
haves like the full delta. 

The best suggestion is if you find DELTA power of 
any flavor and need 208Y/120, forget all ’cute’ ideas 
and simply put an appropriate voltage ratio fully 
isolating 3 phase delta-wye (primary, secondary) 
transformer in there and get honest 208Y/120 out, 
regardless of what was or wasn’t grounded on the 
input. 


This is a feature of most transformer based com¬ 
puter room power conditioners (e.g. Dec’s H9772- 
xx), but could be done with just an inexpensive 
transformer. 

Note that the transformer was specified as DELTA 
primary and WYE secondary. You won’t get a WYE 
primary, normally. The DELTA primary connects 
equally well to a WYE or DELTA source - just get 
the right voltage. 

The NEC has specific categories of allowable de¬ 
vices and locations. There is an up to 120 volt to 
ground category (their wording includes ’nominal’ - 
so 125 is included). There is yet another that tops 
at 277 volts to ground. That is the phase to neutral 
voltage for 480Y/277 circuits voltage is extremely 
popular. Even a modest 5 ton computer room air 
conditioner with electric reheat and humidifier 
needs a formidable hunk of wire to run it at 208Y/ 
120, but, as an example, uses a significantly smaller 
cable if at 480Y/277. 

A plain 2 wire branch circuit using a phase leg and 
the neutral and protected by a single pole 20 amp 
breaker normally can be loaded to 80% (16 amps). 
Any quality wall switch carries at least a 277 volt 
rating. Standard fluorescent fixtures are readily 
available with either of 2 different voltage ballasts, 
120 volt or 277 volt (note: NOT 240 volt!) - same 
price. At 120 volts and 16 amps you can put 1920 
watts on that circuit, at 277 volts you get 4432 
watts. Many buildings do their general distribution 
and power everything possible at 480Y/277, and 
have small transformers on each floor to supply the 
120 volt outlets. Seldom are these transformers 
then large enough to carry a sizable new computer. 
480Y/277 is nice! But if that is what is lurking in 
your computer room you will need a transformer. 
The 480Y/277 is generally hauled over to the center 
of the computer room, fed into a power conditioner / 
distribution system (fancy transformer + integral 
breaker panel) sitting smack in the middle of the 
power hungry cabinets, and transformed, filtered, 
voltage stabilized down to 208Y/120. and from there 
distributed. 

If you still have anv RP04 class drives you really 
need 3 phase, and if any 2 phase legs are inter¬ 
changed. vour disk spins BACKWARDS. Newer de¬ 
vices, such as CDC-9766s typically come at 208 
volts single phase. The cord has 3 wires. The green 
frame ground, and 2 phase legs. NO neutral. 
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Many DEC cabinets (now we get to where this all 
was heading - finally) want 30 amp 125 volt (same 
as 120, or 115) 3 wire outlets (frame ground, 
neutral, and 1 hot wire). If their needs are a bit pig- 
gier, this turns into a 4 wire circuit (just add an¬ 
other hot wire - must be a different phase leg so 
neutral conductor current doesn’t climb). So far 
either of these 3 or 4 wire popular DEC connections 
could be fed equally well from a 208Y/120 3 phase 
service, or plain old 120/240 single phase. For the 
piggiest cabinets they want to add yet another 
phase leg (hot wire) bringing the total to 5 wires. 
This delivers 3 times what they got with a 3 wire 
cord. Can you blame them? 

But, the same rule applies. The newly added phase 
leg MUST be different from the previous 2 again to 
keep neutral current down. Single phase power 
can’t do this. You need 3 phase power. All this to 
power a cabinet that in many cases ONLY needs 
120 volts 2 wire (hot + neutral) + the 3rd safety 
green ground to each of several separate loads in 
the cabinet. 

Ignoring the machines that really need the higher 
voltage or 3 phase, a large cabinet nominally need¬ 
ing 30 amps 208Y/120 could be fed with 90 amps 
120 volts! Why not! You could take the 3 hot legs 
in the cabinet’s cord and feed them the from the 
same phase leg with a 90 amp breaker, BUT the 
wires are then NOT individually protected, AND the 
neutral wire in the cord originally sized for 30 amps 
now carries up to 90 amps. The same goes for any 
similar neutral wiring inside their power controller. 
DON’T DO IT. 

You could buy 3 old 861-C 120 volt power control¬ 
lers each with a 3 wire 30 amp 125 volt cord and 
plug and provide each with its own 30 amp 125 volt 
branch circuit. The individual 120 volt loads in the 
cabinet could then be evenly distributed between the 
3 controllers hogging the bottom of the cabinet. The 
controllers can be set for remote control and wired 
to all switch together, if necessary. 

DEC’s remote control wiring seems to just be to 
turn things off and on all together. I have never 
been aware of any sequencing they do at the power 
controller level. One of the 3rd party power control¬ 
ler manufacturers (either Marway or Pulizzi) has 
been claiming some power sequencing ability in 
their controllers. DEC’s RA81 disks can be se¬ 
quenced with the drive’s sequence cables. The RA60 


drives never had this capability. From their respec¬ 
tive books the following startup currents were ex¬ 
tracted. The vastly different times makes this an 
apples to oranges comparison. These are all just the 
120 volt 60 Hz ratings. RA81s run at 7.8 amps, but 
take a 35 amp peak surge for 4 seconds to start. 
RA60s run at 7.5 amps but pull 190 amps for 1/2 
cycle (1/120 second) to start. 

If you do not have 120/240 or 208Y/120, plug your 
RA60 into a separate 120 volt outlet, but if your 
wiring is that old, pray. Some households do run 
ranges and dryers and water heaters on 208 rather 
than 240 volts and don’t even know it. If you are in 
a large CONDO or apartment building, there is a 
fair chance there is 208Y/120 power. They may only 
bring 2 phase legs to any one tenant (so they can 
use the cheaper 120/240 single phase style breaker 
panels) and they give different pairs of 2 phase legs 
to different tenants to balance the load. You still 
only get 208 between the two hot legs. 

Simple resistance heaters will use 75% of their 240 
volt wattage at 208 volts ((208/240)**2 ). At least 
until the voltage drops so far they stall or burnup 
overheating, motors will fair somewhat better be¬ 
cause as the voltage drops, the motor will draw 
more amps (as it tries to maintain synchronous 
speed) rather than less as a heater would. Many 
window air-conditioners have a dual rating and just 
produce less cooling at 208 volts but run. Some 
MUST be retrofitted with a ’HARD START’ or low 
voltage kit because they were originally not engi¬ 
neered as conservatively. This may be an additional 
run capacitor, or a small temperature sensitive va¬ 
ristor to wire across the run capacitor to give 
higher starting torque. Some devices simply can’t 
be run on low voltage and are best dealt with by 
using a 32 volt boost/buck auto transformer wired 
to boost. A developer building such a building can 
often simply order appliances setup for 208 volts. 
Heater coils are sized accordingly. The tenant gets 
stuck ordering an air conditioner for the wrong volt¬ 
age because no one told him he had 208 volt power. 

Of course there are many other problems, such as 
power factor where current drawn may not be in 
phase with the voltage, but they are beyond the 
scope of this note. 
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Editor’s Thoughts 

This month, we have three articles on three very diverse topics. First is 
What’s a SVID? by James Livingston. Jim gives us a brief recap of the 
development of Unix, setting the stage for an explanation of the SVID. He 
concludes with some very positive statements about the SVID - more positive 
than one usually reads from users of Berkeley Unix. 

Next, Unisig Returns from Triumphant Swiss Tour by Kurt Reisler, our 
illustrious Unisig Chair. Kurt and several other Unisig steering committee 
members recently attended the Swiss DECUS Symposium in St. Gallon, 
Switzerland. I think his account of the trip will be interesting and 
informative to all. 

And third we have another article from Jim Livingston, UNIX vs OS/2: Is 
There Really a Battle Here? Jim cuts through a lot of the hype and dogma 
of the Unix-OS/2 discussion. He gives a brief description of OS/2, and even 
has some good things to say about it. 

Unfortunately, there were no jokes submitted for the Joke of the Month 
contest. So everyone who simply didn't get around to sending in their jokes 
will send them for next month's contest, making next month's contest that 
much more competitive. I'm looking forward to some major yuks from my 
mail next month! Don’t let me down. Instead of the Joke of the Month, this 
month there will be a one-time only contest. The first 20 people who send 
me a note (hardcopy) saying that they read this Unisig newsletter, and 
including a self-addressed, stamped envelope, will receive a crisp, one dollar 
bill. If you want to include any other comments with the SASE, they are 
always welcome. 

As always, your comments, suggestions, and articles are encouraged. Please 
send hardcopy to : 

Sharon Gates-Fishman 
NDC Systems 
730 E. Cypress Ave. 

Monrovia CA 91016 


or e-mail to: 


amdahl!cit-vax!ndc!sgf 



What’s a SVID? 


by James Livingston 

There are, in the UNIX world, lots of implementations of the operating 
system characteristics which, taken as a whole, are identified as UNIX. I 
leave out, by the way, an entire collection of things which are called 
"UNIX-like" There are enough differences between full UNIX 
implementations that it's useful to say, in a general way, what are the 
general trends to be seen in just this class. It's likely that "UNIX-like" 
products are a transient phenomenon, anyway. 

As you might expect, AT&T is a central corporate figure in the UNIX 
world. It is, after all, their invention. They sell supported licenses for a 
number of UNIX implementations (ten, as of their most recent count) for 
different computers, and have spent considerable money on promoting their 
current version, which is called "UNIX System V, Release 3.0". Can you 
imagine anyone in our industry (or out of it. for that matter) having failed 
to see their "Consider it Standard" advertising campaign for generic UNIX 
System V? 

It is AT&T's stated objective to make UNIX System V an industry-standard 
operating system, and that's not as purely self-serving as it may appear at 
first glance. There is little disagreement that standards have beneficial 
effects when they're adequately observed, whether they are officially blessed 
by some standards body like ANSI, IEEE or ISO, or simply the result of a 
fact of life, like IBM PCs. 

Certainly industry-wide adoption of a UNIX standard would make life 
simpler for application developers, and it is they who will determine the 
ultimate fate of the operating system. Whether or not it's a good idea for a 
single vendor exclusively to define a standard is a different question. I'd like 
to spend more time on the general matter of standards, and on the standards 
movement in the UNIX milieu, in particular, but I think that's better left 
for a column of its own. 

A second major force in the development of UNIX as we know it today is 
the University of California at Berkeley's Computer Science Research 
Group. It is they who are responsible for the 4BSD versions of UNIX, 
which were developed for the VAX from the initial (non-virtual) UNIX- 
32V implemented by Bell Laboratories. A number of computer system 
vendors, most notably Digital and Sun Microsystems, base their operating 
systems on 4.2(3)BSD LTNIX, the latest releases from Berkeley. 

So the primary forces in the UNIX marketplace are AT&T's System V, and 
Berkeley's 4.2(3)BSD. These two versions of UNIX are different in a 
number of ways that make it difficult to write common applications software 
for them, as well as to transport users easily from one to the other. If it 
were not the case that derivatives of 4.2(3)BSD are the only (available) 
successful VAX implementations of UNIX, it is not hard to imagine 
AT&T's dominance of the UNIX market becoming beyond effective 
challenge. 
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As it is, however, AT&T have chosen not to continue supporting System V 
on VAX hardware. That means there's a place for 4BSD UNIX for the 
forseeable future. This situation, in the worst case, could guarantee that 
there’ll be two major variants of UNIX as long as there are VAXen, and 
that its opportunity to become a widely-used operating system standard will 
remain unexploited. We’ll see below how I think this impasse is likely to be 
avoided. 

Let’s consider now what would be the most important aspects of an 
operating system, from the point of view of the applications developer. 
First, of course, is the presence or absence of a certifiably portable language 
for creating applications. There are a number of such in use today, although 
C, the implementation language of UNIX, itself, is not yet one of them. C 
is, however, in the midst of a nearly-complete IEEE standardization effort, 
and so will soon be made available in a consistent form across a number of 
operating systems, including, but not restricted to UNIX. 

The next factor the applications developer must care about is the form of the 
interface to the services of the operating system. If that interface is 
syntactically and semantically consistent across instances of the operating 
system on different hardware, the developer is assured that applications will 
run in the same way, regardless of the underlying hardware (timing 
considerations excluded, of course). 

Enter the System V Interface Definition (SVID), a product of AT&T that I 
think has considerable merit. It is a definition of the syntax and semantics 
of the services provided by the UNIX System V operating system, given in a 
published prose form. It specifies, for example, the effect of issuing a 
”malloc()" memory allocation system call, together the C syntax for the type 
and number of its arguments and function return. 

The SVID doesn't look to me like a static document that will be quickly 
made obsolete. It has had two issues since its introduction in January l c )85. 
and has grown from one to three volumes. The first two describe the 
"System V Base" and "Kernel Extension". The second gives five more 
extensions, "Base Utilities Extension", "Advanced Utilities Extension", 
"Administered Systems Extension”, "Software Development Extension", and 
"Terminal Interface Extension". The third volume describes an "Enhanced 
Terminal Interface Extension" and a "Network Services Extension". 

The purpose of this publication, in the words of AT&T, is "...to help 
establish a single UNIX system standard, and thereby encouraging!sic] the 
development of portable applications software, and. finally, to offer end- 
users a wide range of computers with compatible operating systems and 
applications." For the moment let's leave aside the fact that successful 
establishment of this standard would give AT&T a competitive advantage, if 
one that is likely to be short-lived. It does provide one way to accomplish 
the goal they’ve set, and that we'd agree is desirable. 

As a reminder, I said above that the SVID wasn't the only thing happening 
on the UNIX standards front. Other efforts are afoot, and may well have 
an effect on the SVID, itself. Still, it's here, and being maintained by 
AT&T. It provides a prescription for making a "standard" UNIX. All a 
hardware vendor must do is implement it, and all the applications which are 
available for UNIX will run on it, and the vendor can so claim. What could 
be wrong with this picture? 
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Well, this may be shocking, but some folks in our industry have been known 
to claim capabilities for their systems which, upon investigation, have been 
strangely absent. So what's to be done about this sort of vendor? Make it 
possible to certify conformity to the "standard" is one answer. That strategy 
has been used to good effect for languages, in the past. 

AT&T evidently think it's a good strategy, too; they offer a SVID 
Validation Suite (SVVS) to go along with the SVID. With that, vendors can 
verify their conformity to the SVID for themselves, and lay legitimate claim 
to adherence to the standard by getting AT&T to certify their claim with the 
same SVVS. Mind you, all this has a cost associated with it, but that. too. 
is another story. 

So now you see what I alluded to in the first part of this discussion: IJltrix- 
32, version 2.2 is based upon 4.2(3), but includes the features of System V 
to a degree of faithfulness which enables them to be certified as in 
conformity with the SVID. I believe that certification only applies to release 
2 of System V at this moment, but it would not be beyond imagining that 
Digital would have a subsequent Ultrix release validated against the new 
issue of the SVID. 

Whether or not Digital chooses to do this will depend upon their perception 
of the market's demand for it; as I said, it's not free, and if there weren't 
demand from customers for it, certification against the SVID wouldn't make 
good business sense. On the other hand, one or more of the other standards 
efforts may come to a fruition which obsoletes the SVID. My bet would be 
that whatever the standard becomes, finally, it will owe a considerable debt 
to the SVID. It will be an interesting development to watch. 
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UNISIG RETURNS FROM TRIUMPHANT SWISS TOUR 

by Kurt Reisler - UNISIG Chairman 

The UNISIG Traveling Symposium Tour has returned from an 
unprecedented and highly successful trip to the DECUS Switzerland Spring 
Symposium which was held in early March in the city of St. Gallen. While 
it is not unusual for members of the US Chapter Board of Directors to 
travel to non-US symposia, this trip was unusual in that it was the first time 
that an international trip was jointly funded by the Boards of the US 
Chapter and the host country. Additionally, this was the first time that 
members of the US Chapter travelled to a foreign chapter for the specific 
purpose of providing (technical) speaker support (in this case, for the Unix 
and OA streams). 

The trip came about as a result of many months of joint effort by members 
of the US Chapter's UNISIG steering committee and the Swiss Symposium 
Coordinator, Graham Tritt. The Swiss initially contacted the UNISIG 
Chair (Kurt Reisler) in late September 1987 to enquire about the 
possibility of providing speakers for the forthcoming .Swiss symposium. 
After discussions at the UNISIG Woods meeting in October 1987 
established that the UNISIG Steering committee could, indeed, provide a 
speaker pool for the Swiss Symposium, the "negotiations" began in earnest 
via electronic mail (over uucp). Once a tentative schedule of both 
symposium sessions and presymposium seminars was established, both the 
Swiss and US parties had to present the proposal to their respective Boards 
of Directors to obtain approval for the necessary funding. 

Several written presentations were made to the members of the US Chapter 
Board of Directors at the Fall '87 Symposium in Anaheim. Core members 
of the the UNISIG Steering Committee augmented the written presentations 
during meetings with individual members of the Board and subsets of the 
full Board. Several conference calls to Switzerland were also made to clarify 
various procedural and financial issues. The eventual outcome of these 
efforts was the unprecedented (and experimental) joint funding of a trip 
to the Swiss DECUS symposium by members of the UNISIG steering 
committee. 

Although the original proposal provided for sending 10 speakers to 
Switzerland, various Stateside commitments limited actual participation to 
seven members of the steering committee. The extremely varied technical 
background of those members w'ho did participate, coupled with an 
extraordinary amount of advanced preparation made it possible for the 
seven UNISIG steering committee members to present 6 pre and post 
symposium seminars and 12 technical sessions at the symposium itself. 
Additionally, several members of the UNISIG steering committee 
participated as panelists in three other technical sessions organized by the 
Swiss. Steering committee members who made the trip included Kurt 
Reisler (UNISIG Chair), Dorothy Geiger (Administrative Daemon), 
Steve Lazarus (Symposium Coordinator Emeritus), Steven Stepanek 
(Seminars Representative), Ed Gould (Standards Coordinator), Bill 
Cheswick (Session Notes Editor), and Jeff Gillium (Member at Large). 
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The group departed the United States from various cities on both coasts on 
Friday, March 4th arriving almost simultaneously in Zurich on the morning 
of March 5th. After collecting baggage and counting heads in the customs 
area of the Zurich airport, the group boarded the train for St. Gallen, site 
of both the pre-symposium seminars and the symposium itself. That night, 
UNISIG was finally able to meet the members of the Swiss Board with 
whom they had been working so closely (yet at such long distance) for the 
past several months. After meeting with the Swiss Board, UNISIG took 
advantage of the presence of the majority of the steering committee to hold a 
Woods meeting at which they planned for the Cincinnati and Anaheim 
symposia (minutes for the Woods Meeting will be published separately). 

The first of the presymposium seminars were held on Sunday the 6th, with 
additional seminars held on Monday the 7th. The Symposium itself was 
held from the 8th through the 10th, with the UNISIG speakers presenting 
continuous session streams on the first and third days. Post-symposium 
seminars were then held in Geneva and Bern on the 12th of March. No 
UNISIG sessions were scheduled for the second day of the symposium so 
that the Steering Committee members could have a day to attend sessions, 
recover from the trip, or participate in a marathon training session that 
took place in a variety of cities around Switzerland. Since English was the 
"official language" of the symposium, there were no major language 
problems during the sessions. 

Audience reaction to the sessions was uniformly enthusiastic; the normally 
reticent Swiss asked many questions during and after every session. 
Although only 2% of the more than 350 attendees were Unix users, nearly 
10% of these attendees attended the Unix sessions. Surprisingly, the Unix 
sessions drew well even when scheduled directly against the "heavy duty" 
VAX sessions. 

At the conclusion of the Symposium, Kurt Reisler and Dorothy Geiger 
were invited to attend a meeting of the Swiss DECTJS Board of Directors. 
This meeting served as a wrap up for the symposium, a planning session for 
the next symposium and a general business meeting for the Board. All of 
the Swiss Board members were extremely pleased by the cooperation 
between the US and Swiss Chapters, and with the quality and quality of the 
UNISIG sessions. 

As a result of the "UNISIG Traveling Road Show", it is anticipated that 
there will be more such cooperative efforts between the US and other 
DECUS chapters. In addition, some members of the Sw'iss board are 
planning to not only attend US Symposia, but to present technical papers as 
well. All participants in this experiment have high hopes that cooperation 
between the US and International DECUS chapters will continue to flourish. 

The Unisig Steering committee w'ould like to express their thanks to the 
Board of Directors of the US chapter for approving the funding of this 
trip, and to the Swiss Board for their approval and funding as well. It is 
worth noting that without this jointly funded effort, there W'ould have been 
only a single Unix session at the Swiss Symposium. The Swiss have 
reported that this effort has fostered increasing support by Digital (Europe) 
for Swiss DECUS. 
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UNIX vs OS/2: Is There Really a Battle Here? 

by James Livingston 

I read many of our industry's publications, as I expect most of you do. One 
of the topics I find cropping up more, of late, is the "developing battle for 
supremacy" between UNIX and Microsoft and IBM's OS/2. I use quotes to 
indicate that I'm not sure just how meaningful is the notion of a general 
battle between UNIX and OS/2 for the title of "supreme operating system”, 
or some such. 

In fairness to its participants, I must admit that the dialogue to which I refer 
tends to be focussed upon computing in the business office, rather than in 
the wider computing environment. Further, it is usually found in the 
context of microcomputing, a further limitation on the marketplace under 
discussion. 

Still, the "contest" is getting coverage in the wider marketplace of ideas, and 
the assumptions I've mentioned aren't always prominently featured. 
Moreover, the recent emergence of the workstation marketplace has added 
some new implications to the dialogue. This leads me to think some 
discussion of the UNIX vs. OS/2 issue from a broader perspective could be 
useful. 

First, I should note that, by OS/2, I mean the operating system being 
developed jointly by Microsoft and IBM for the "protected" operating mode 
of the Intel 80286 and 80386 microprocessors. While it was announced with 
the PS/2 series of IBM personal computers, it is currently available in 
preliminary form only, supporting just the 80286, or 80386 running in 80286 
emulation mode, and suitable for use only by software developers. 

This operating system enables the use of the 16Mbyte address space 
inherently available to a process running in an 80286. Yes, that's the 
microprocessor in the PC/AT and clones, now including the VAXMate, that 
have been trumpeted for the last two-plus years, as we see in the awful ad 
copy from computer retail stores, to have access to "...a full 640K bytes of 
RAM memory![sic]" under DOS 3.x. 

No delivery date has been announced for native 80386 support, either. 
That's right; the way you use the cheap, widely-available 80386-based 
machines with OS/2 is as fast (16-bit) 80286es, and it's not known when that 
will change for OS/2! By the way, the little beggars are really quick on 
small, computationally-intensive benchmarks like the Sieve of Eratosthenes, 
even in this limited mode. We'll come back to a more general look at 80386 
vs. other processor performance issues in another column, however. 

As an interesting aside, Microsoft are reported to have sold some 2000-plus 
of their preliminary developer's kits in the last nine months or so, at about 
$3000.00 apiece. I think $6M+ is a nice gross on a partial beta test, don't 
you? Maybe these personal computer software vendors have something to 
teach the wider computer industry about profit-making? 

OS/2 is intended to be the replacement for MS-DOS on microcomputers with 
memory-mangement hardware. In contrast to the latter, rather simple- 
minded program loader, OS/2 is a real operating system, if a single-user one. 
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It uses, in the current preliminary release, the hierarchical file system of 
MS-DOS. Apart from the lack of support for multiple users in this file 
system e.g., groups of access permissions, it looks to a user about as you 
might expect. 

One shortcoming most Digital users will identify right away is that file names 
can have at most eight characters, and file name extensions three. UNIX 
users will also note, with some displeasure, that pathnames are single case 
(upper). In addition, pathnames are set off from device names via while 
directory components are set off from each other and the file name by " 

The capabilities that make OS/2 really interesting are to be found in the 
multitasking support it contains, together with its ability to manage the 
microprocessor's virtual memory capability. Processes are no more limited 
in size in OS/2 than they are in any other virtual system, and there is a 
built-in "lightweight process" notion, called "threads" of execution. These 
threads are minimal process context, i.e., dispatching information, including 
priority, a stack, time slice, processor state, and a mathematical coprocessor 
state. Threads of execution are available in addition to process hierarchies, 
as most of us know them from UNIX and VMS. 

The scheduler of OS/2 provides gross and fine-grained options for scheduling 
processes and threads. It operates generally like VMS, using three classes 
tor processes: time-critical, normal, and idle-time. Thirty-two priorities are 
available at each level, and the scheduler can be told to adjust levels for the 
"normal" class so as to yield a time-slicing behavior. In that time-critical 
scheduling is pre-emptively priority driven, it is somewhat more deterministic 
than is scheduling in most UNIX systems. Further, each thread in a process 
has its own priority. 

To support its multitasking operations, OS/2 provides a rather complete 
selection of interprocess communication mechanisms: pipes, queues, 
semaphores, shared memory, and signals. While the implementation of 
signals leaves considerable to be desired, relative to the least of UNIX 
implementations thereof, the rest of the features should prove to be 
serviceable. 

Queues differ from pipes, mainly, in that they have no maximum 
transmission size like the 64Kbyes of pipe writes. The entries in a queue are 
memory identifiers, or "handles". In addition, queues have specifiable 
protocols, i.e., FIFO or LIFO, and can be emptied in random order by the 
server. 

Use of memory in OS/2 should be tailorable as is that of VMS and UNIX 
System V.3, in that support for shared libraries is present. The precise 
nature of the support is not as clear to me as I would like, but remember 
that not very much detailed information is currently available on any aspect 
of OS/2's features. 

As far as I can determine, the capability exists to create shared libraries 
which, if the routines in them are carefully crafted, can be modified without 
so much as a relink of the application tasks that use them. That would 
appear to require entry-point vectoring, as used by both VMS and System 
V.3, but OS/2 seems to provide the support by making the linker and loader 
conspire to defer binding of these "dynamically linked libraries" until run¬ 
time. I think that the whole business depends very heavily upon the 
segmented architecture of the 80286, but my curiosity will have to wait for 
its satisfaction until more information is available. 
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Last, OS/2 supports the intrinsic memory management capabilities of the 
80286, as I noted earlier. These are as you might expect also: memory 
references go through mapping hardware that associates a descriptor with 
each base address in the mapping table for a process. Access protections are 
enforced, thereby providing protection against errant processes, and virtual 
memory is implemented via segment swapping, as needed. Clearly, the 
systems in which we'll find OS/2 will have hard disks, as most ATs and 
clones do now. 

Well, there is a very brief description of OS/2. You'll note that it's a serious 
entry into the world of operating systems for microprocessors, and that it has 
many features that are similar to those of UNIX. There are, in fact features 
in OS/2 that have been proposed as desirable enhancements to UNIX; 
threads, in particular, come to mind as a feature of Mach, a proposed 
successor to UNIX. So how does one evaluate the question I started with? 
Is there a battle here? 

I think the thing I've done, so far, is to de-emphasize one very important 
fact about OS/2: it runs only on 80x86 microprocessors and therefore only on 
computers which use those microprocessors. While the machines in this class 
are legion, UNIX also runs on those microprocessors, and it uses the native 
capabilities of the 80386. 

That fact makes two things important, to my mind: first, applications 
developed under UNIX running on almost any processor can be ported to 
the 80x86 family UNIX implementations, so there are more potential 
sources for UNIX applications than there are for OS/2 applications. Second, 
the availability of 80386 UNIX engines at today's and tomorrow's prices 
cannot help but spur yet more software development for UNIX. 

But what, you may say, about the ocean of MS-DOS applications that will 
make all our business people rush to buy OS/2 systems for software 
preservation? The UNIX implementations for the 80386 machines that I 
know about have the ability to execute MS-DOS programs as processes under 
UNIX, so they have the same ability to preserve the software investment of 
a business as does OS/2. So, where's the battle? 1 think it's in the minds of 
those who write from the limited perspective of the PC/AT/clone 
marketplace. Yes, there'll be a battle there, of sorts, but it'll be between 
folks whose comparison levels have been formed by exposure to nothing 
more helpful than MS-DOS. Any developer who's used UNIX, and has a 
choice of development platforms, will very likely choose to develop on 
UNIX, even if the software being developed is targeted for OS/2. And 
there's every chance, it seems to me, that she'll develop her application for 
UNIX first, while she’s at it. 
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Contributions and suggestions for this newsletter are constantly needed. Articles, letters, 
technical tips, or anything of interest to our SIG are greatly appreciated. The editor prefers 
submissions be made electronically. Magnetic tape and hard copy will be accepted, but may 
delay publication. 

Please do not submit program source. It is difficult to typeset and is better distributed on 
the VAX SIG tape. Please do not submit “slides” from DECUS Symposia presentations or other 
meetings. They are generally a very incomplete treatment for those readers of the Pageswapper 
who are not so fortunate as to be able to travel to Symposia. Please DO write articles based on 
such slides. 

Send your contributions to: 

ARPAnet/CSnet/NSFnet: ctp@cs.utexas.edu 
UUCP: ctp@ut-sally.uucp ({harvard,ihnp4,uunet}!ut-sally!ctp) 

BITNET: CTP@UTADNX 
CompuServe: 75226,3135 
DCS: POOLE 


or if you must, use the U. S. Mails: 

Clyde T. Poole 

The University of Texas at Austin 
Department of Computer Sciences 
Taylor Hall 2.124 
Austin, Texas 78712-1188 


VAX SIG Advanced Software Q&A 
1987 DECUS Fall U.S. Symposium 


Editor’s Note: The following is a edited transcription of the VAX SIG Advanced Software Q&A at 
the 1987 DECUS Fall U.S. Symposium help on Friday, December 11, 1988 in Anaheim, California. 
No material has been added, but some material has been edited for clarity or removed entirely. 
Comments by the session chairman are not indented. Discussions of a single question are separated 
from each other by centered lines. 

[At the beginning of the session, the Digital VMS software engineers present were asked to identify 
themselves.] 

My names Forrest Kenney I work in the terminal driver. 

I’m Jim Crispa and I’m covering batch print. 

Keith Wolfe, the file system in BACKUP. 

Todd Floulau, DCL and mail. 
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Terry Cassidy, DECnet VAX. 

Scott Davis, VAXclusters or volume shadowing. 

Dave Tiel, VAXclusters. 

Richard Bishop, performance. 

George Clayborn, AUTOGEN and general performance issues. 

Stan Amway, VMS exec. 

Steve Feille, VMS exec. 

James Sing, DECnet VAX performance. 

Wayne Cardosa, VMS exec. 

Mary Edo, DECnet VAX. 

Peter Vatney, RMS and RMS journaling. 

Ron Shaffer, System management and licensing. 

Rod Gamanche, Multiprocessor and Micro VAXes. 

Kathy Morris, just about anything. 

Harriet Cohen, product management. 

I’d do a virtual Andy Goldstein announcement. He’ll be with us in about ten minutes. 

Okay, thank you very much, but before we do anything else I’d like a round of applause for these 
people for being here, not just now but all week and also incidently for creating VMS for us. I 
was asked by Harriet Cohen to ask you a couple of questions just based on show of hands. 

Q. How many of you have MicroVAXes? 

A. That’s about a 100%. 

Q. And, how many are running local area VAXclusters? 

A. About 50, 50% of the room. 

Q. Cl based clusters? 

A. 80 
Q. Both? 

A. About 30%. 

Q. And, how many have either 83 or 88 hundred multi processing machines? 

A. [No answer on tape] 

Q. How about 782s? 782s, show of hands? 

A. A few 
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Q. Okay, how many people only have Micro VAXes and nothing larger? 

A. Okay, I consider that a sampling error, because the sites small enough just use Micro VAXes 
are intend to be the ones small enough to not sent many people to DECUS, but so, that’s 
probably not representative. 

Okay, I don’t think there’s any other things before we get started. Standard DECUS Q&A 
protocol, please state your name and affiliation at the microphone. One question to a Q entry 
and first questioner please. 


Q. Okay, my name is Bill Wisethorne, I’m with Schlumberger Well Services in Dallas and 
hopefully this will set the tone for the rest of the day here. This question I’ve been asking 
several people throughout the week about and have been bunching from one to another, 
so since I’ve got you all in one place, maybe this will get an answer. We have a situation 
where we’re running 780s in a wide area network, using satellite links and we are trying 
to get some better performance out of our link. We are currently using a 112KB line and 
our effective throughput is approximately 30KB. Now, we’ve gone through and I’ve talked 
with the hardware people and they seem to think that the problem was the DECSA router, 
so I had my people take that out of the chain and we ran a test this week that went from 
a 4.6 machine in the Richfield, Connecticut to our 4.5 machine in Denver and we still got 
the same 30KB throughput on our 112 KB line. We’ve played with line buffer size, we’ve 
played with transmit pipeline quotas, pipeline quotas, anything and everything we could 
get our hands on that even looked remotely like it would effect the performance. Where 
do we do from here? 

A. I believe what you want to do is make sure that both nodes are running VMS 4.6 and 
then you want to make sure that the transmit pipeline, the numbers, well depending on 
the satellite link, you want to make sure that’s a fairly high number. I think it defaults to 
somewhere in the order of 6 or 8 and you want at, maybe, . 

Q. Right, we had it up to 32, we tried it anywhere between 25 and 32. 

A. But, on the 4.5 system I don’t believe it’s working properly. 

Q. So, transport pipeline then is definitely without a doubt... 

A. That’s the one that’s going to keep the packets in the air without acknowledgements, that’s 
the thing you’re probably going to want to twiddle most to try and get the performance. 

Q. Yeah, because when we first tried this, we had both systems running 4.4 and we didn’t see 
any difference. We called software support and they said, hey that’s news to us, it works 
as far as we know. 

A. I think you found that it didn’t work the way we thought it did and.... 

Q. So, if we upgrade everybody to 4.6... 

A. All you have to be concerned about is the 2 nodes that are talking over the satellite link. 
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Q. Peter Elky, with Phoenix Leasing. On the next major release, on the terminal driver 
changes how is communicating with terminal set to /MODEM....before a carrier is present., 
specifically for outgoing things or talking to devices that supply carrier only for notification 
of the connection or not and not so much for preventing you from talking to data.... 

A. The change doesn’t affect outgoing lines at all. There’s nothing changed in that at all. 


Q. Stan Rose from Bankers Trust. Terminal driver question, another one. We would like to 
be able to set terminal characteristics on the prototype UCB, UCBO, for devices like NV 
devices, LAT devices, so we can have different characteristics. We might want to have sys 
mass words on for NV devices and not on for LAT devices and other things of that nature. 
It seemed that would be a fairly [simple] change to allow us a SET TERM NVO or LTAO 
and it would take care of all of that, today we have to do it by just patching it, we don’t 
want to do. 

A. Really, noted, because of the way the devices are constructed what appears to be simple 
is really not. It would require inventing a new mechanism for manipulating devices. We’ll 
take it make and look at it for some future time after future unannounced. 


Q. John Burnett, STS Consultants. I had a DECnet VAX question. This may be fixed in 4.6, 
we’re not running 4.6 yet and if it is fixed I’d like to know about it, otherwise I’d like to 
know what we can do. Apparently the NCP SET LOGGING SYNC NODE option does 
not work. We have tried this and we’ve tried to set the sync node up to be a different node 
on the local node and it does not change it either the volatile or the permanent database. 
Basically it does not send the events over the net the sync node. What we’ve had to do 
to get around that is say, NCP SET LOGGING FILE node:: the device we want. We’re 
just trying to send it to the terminal, hard copy for logging purposes. Can you give me 
any idea about why that’s not working in 4.5? 

A. No as a matter of fact it really is a new bug to me, I haven’t even heard of that. 

Q. Okay, so that’s not a known problem that would be fixed in 4.6 or this future.... 

A. No, definitely not 4.6. 


Q. Okay, another problem related to that that cropped up when we did the work around 
was that when we do SET LOGGING NAME node:: terminal name: what we find is 
we’ve got an 8200 which is supposed to be the logging console is on that and then we’ve 
2 MicroVAXes running MicroVMS 4.4 connected to that among others, those are the 
important ones. 8200 is running VMS 4.5, we find that we have fail processes hanging 
around and failing to exit fail and revert to net server processes. When they connect up 
from the MicroVMS 4.4 nodes to create a fail process on the 8200 on the VMS 4.5 they 
open the file which is just a terminal write the stuff to it and close it and I’ve turned on 
fail dollar log/logging for the Net server processes for the fail processes, apparently what’s 
happening is it’s in a closed operation, it’s waiting for a receive AST that’s never delivered. 
So, those two fail processes from the remote, MicroVMS nodes hang around indefinitely. 

A. All right, just at [this] DECUS I’ve heard of another problem with fail poses the same 
around and that’s fairly new to me too. I haven’t heard of that and I know there’s no fix 
so far in 4.6. 
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Q. Dennis Costello, Cornell University and I have several VT340s and apparently they are 
now supported in VMS 4.6, so I like that. However, they do not seem to be supported in 
FMS or WPS and there doesn’t seem to be any kind of software that does anything with 
the mouse and I’m wondering if anybody wants to comment on any of those three. I was 
able to get WPS to work, but FMS is still a mystery. If I set the 340 to really be a 340 
instead of pretending to be 240, on 4.5 it wasn’t recognized, in 4.6 it comes up and says 
it’s a VT300 series terminal and that works fine. However, if it’s set up that way WPS will 
not start up correctly, it will now because I patched the WPS Plus Dollar logging, just for 
log in command file. FMS I have not been able to get it to work on a 340 unless I tell it 
that’s it’s 240. 

A. .What you’re seeing is the fact that some of the layered products have not caught up with 
the new terminals and you really need to take these problems directly to the developers of 
those products. 

Q. Does anything support the mouse? 

A. Nothing that I’m aware of. The mouse is really only supported in ReGIS node and so to 
use it you kind of have to write your own locater port support for it at this time. 


Q. Dave Cooke, Maxi Care Corporation, I’ve a VMS system services question. We have an 
AST routine that is running as a result of a supervisor mode AST delivery, one of the 
things that the AST routine does is it queues a VMS lock to a user mode resource. We 
found that while it queues the resource to the correct resource block, the lock block itself 
is taken out in the supervisor mode. Our problem is that then when we fall out of the 
AST routine and revert back to user mode we can’t delete the lock because now we’re in 
user mode and it doesn’t recognize that it’s a supervisor mode lock block. We tried to 
use the declare change mode handler to get us into supervisor mode to delete the lock and 
found that you have to be in the mode that you desire in order to declare the handler. 
Consequently it doesn’t appear that there’s anyway to get to supervisor mode. Do you 
have any comments on this? 

A. Well, it’s if you want the lock to [be] accessible from user mode, it sounds like what you 
should do is be specifying user mode in the optional access mode in the end queue call to 
begin with and that will make it a user mode lock. 

Q. The access mode field in an NQ system service only impacts the name space that’s used, 
it does not impact the ownership protection of the lock. 

A. Right it applies to the resource block, not the lock block. The lock block is taken out in 
the current mode. 

Q. When you try to delete the lock block from another mode it doesn’t see it. 

A. Well, it’s not that it doesn’t see it, it’s that the protections prevent you from manipulating 
it. 

Q. Correct, yeah the same affect. 

A. So, you are on the right track by trying to get into supervisor mode to manipulate the 
lock.... 

Q. Right, our problem there is that first of all you can’t... in order to declare a change 
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mode handler you have to be in the mode that you’re declaring the handler for. You 
cannot change mode to supervisor because the DCL dispatcher does not recognize non 
DCL vectors. Now...so consequently you’re pretty well locked out. The only way that we 
could come up with was to change mode to Exec and then drop back down, but that’s a 
real cludge. 

A. That would certainly work. I believe that you could also manipulate the lock from executive 
mode. 

Q. Oh, so change mode exec and delete the lock from exec mode? 

A. Yes. And, in that case I believe you would have to specify the access mode, not to indicate 
the privilege of the lock, but to be in the right name space. 


Q. Jim Brosiato, Computer Systems, Consultant. On native BI processors with a native 
Ethernet interface several versions of VMS from some of the recent field tests versions up, 
the ET driver complains about something it doesn’t like in the micro code of ZEBNX, the 
messages have gotten a little bit subtler since some of the field test versions, but it’s still 
complaining about something on both DEBNT systems and DEBNA systems, what do we 
need to do to satisfy the driver, what is it trying to tell me and what might I be missing 
by not solving this problem? 

A. I’m just trying to remember now....I’m almost sure that it means that there’s a certain 
level I know of VNT that’s out, that ET driver doesn’t support or it’s warning you that it 
doesn’t support and there’s an ECO or FCO that you have to apply to the board. 

Q. This is an 8700 that was installed last October. 

A. That could still be that that has to be applied. Is it a VNT that you’re talking.... 

Q. In the 8700 it’s a DEBNA, the latest and greatest. 

A. I am a little surprised at that. I thought the problem was the VNT code, all I can do is 
say, you know, SPR the problem, if it really is a BNA. 

A. (from audience) Stan Rose. I’ve given this about three times today, since I picked it up this 
morning at the network session. Here’s the information on DEBNET and the DEBNA. 
The DEBNET is being replaced with the DEBNA which will be at rev F and that’s done 
by part number EQ-01486-01. Now the DEBNA is probably today at rev D and that’s 
being replaced with rev E DEBNA. The rev E DEBNA you get by getting part number, 
these aren’t the FCO number’s, these are the part numbers, EQ-01500-01. Once you get 
those upgrades, either the DEBNA to DEBNA or the DEBNET to upgrade you then need 
a new ET driver which it goes on 4.5 or 4.6 and the part number from field service to get 
that is EQ-014500-02, but I think it may be just 01500-02, I’m not sure about my hand 
writing. There is also a new diagnostic to support that and that’s EQ-01500-03, okay, 
so there are four part numbers there, one for the DEBNA to DEBNA, one for a DEBNA 
upgrade and one for a new ET driver and one for new diagnostic and the person who spoke 
earlier said do not run the new ET driver with the old DEBNET or the old DEBNA.... 

A. Sounds right, thank you. 

A. (from audience) There’s one more piece to that that Lance Schmidt, if he’s still around 
can speak about and that is ?????? from Dow Chemical. It turns out there’s a text file 
that is referenced during the start up on any 8xxx machine with Pro-380, I think you said 
it was an 8700. Okay, the test file is horribly out of date, in fact it’s banished in rev 6 of 
the Pro-380 counsel code as I remember from the release notes. The test files been out of 
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date for a couple of years apparently. 

Q. What ET driver comes with the 4.5 and 4.6 distribution kits. 

A. Which one? 

Q. What do I need to do to make this thing right. What ships with the kits? 

A. Well, what you have to do is apply the upgrades. I’m fairly sure that the ET driver in 4.6 
is a fairly rewrite of the one in 4.5. So, what you want to do is to upgrade your BNA to 
what was it E or F and then go up to 4.6. 

Q. Previously things like this where hardware was coupled to software showed up in the release 
notes, what happened this time around? I can’t believe that I’m the only person that’s 
seen this. 

A. I’m not too sure why that didn’t hit the release notes. 

Q. How many people have seen this problem? 

A. Well, we’ll make a note to make sure that 4.7 or if we can put the note in 4.7, release in. 


Q. My name is Richard Garlette, I work at Bankers Trust. My question concerns logging of 
memory errors. In order to save logging redundant errors, VMS....apparently logs only a 
fraction of the actual errors or it may start logging the errors depending on the rate of 
errors, so you have several kinds of thresholds there either an absolute number of errors 
or an absolute number errors per time and that’s fine. However, what we’ve experienced 
on 8000 series machines, this 8700s, is we would get a few errors, that is one a day, and 
the machine maybe booted once a week so we would get seven a week. Now the threshold 
for absolute number of errors is sixteen, so as a result we would never see the log entry for 
any of these errors. Now you might say, well don’t worry about it, however, we worried 
about it and field service said don’t worry about it and the next night after that meeting 
there was a catastrophic failure and the machine crashed because this one a day suddenly 
became, you know, five thousand per second or something. We’ve asked field service, we’ve 
asked CSC could they change the logging thresholds so that at least you log the first and 
the seventeenth rather the sixteenth and the thrity second so that you would always get a 
log on the very first one or the very first queue, even if you don’t log all of them so that 
we could see what these were and the field service could think about and the only thing 
we’ve got so far is a workaround going into the system using SDA and actually reading out 
the buffers which are in memory and give a bunch of X digits to the field service people 
and they scratch their heads on what that means. We’ve SPR’d this months and months 
ago and really haven’t gotten much of a response. It seems like a very simple fix, at least 
a simple minded fix to start logging in number one rather than number sixteen, if that 
happens to be our threshold. 

A. Okay, first in case...not everybody realizes that only refers to corrected errors, not to hard 
errors. 

Q. Yeah, they were corrected until that famous Tuesday night. 

A. And, basically that algorithm was the consensus of memory engineering, field service and 
CSSE and we do what they asked us to. They felt that logging on an occasional one 
provides absolutely no information. Not being a memory expert I won’t attempt to defend 
that, I’m simply explaining why we do it. 

Q. Yeah, on the other hand one of the group said in Colorado that we recently had spoken 
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to on some of the new facilities that allows them to analyze proactively possible error 
situations putting more intelligence into VAXsim and products like that say they were 
very surprised that there’s data out there that’s not available to look at it and so, you 
know, I speak to you as a corporation and I think you have to accept the question as a 
corporation. If there’s somebody somewhere else that gave a different opinion, you know, 
we really would like this sort of thing addressed, because a simple minded analysis in this 
case was correct. Namely you get one a day, sooner or later it’s going to catastrophic. No 
matter what anyone else tells me I’m going to believe that because that’s always the way 
things tend to work, so I think that you have the information there let us look at it. 

A. Okay. Noted. We’ll check and see if they’ve changed their opinion. 

Q. You might tell them your opinion, too. 


Q. Dick Nickcart, Kalamazoo College. Ever since we’ve put up version 4.6, when we backed 
up our user files, we have occasionally gotten messages, always in pairs saying that there 
was a warning that RMS journaling was before RMS journaling and after RMS journaling 
was not going to be enabled on the copy or something like that and the syntext of the 
message I don’t remember, except that it had an obvious place at the end for the file name 
to appear but it didn’t. We don’t have RMS journaling and never have. The number 
of occurrences of this message is growing. Earlier I raised the issue and was told that I 
probably had a system management message file mismatch, so I went back and I called 
home and my operator did a differences of the listing file of the first and second shipments 
of the VMS 4.6 that we got and they’re identical. I obviously can’t compare it to the write 
copy, but I’m curious...first off it puzzles me...if I were to get RMS journaling in the future 
that I might do a back up and restore and lose the journaling. 

A. I think I talked earlier this week about this, the problem is that in the release of 4.6 at 
one stage we did get the sys manager message file confused. If that’s still confused than 
you really need to talk to telephone support and get that sorted out and get the date of 
the file sorted out. 

Q. We got a second shipment, a whole second shipment. DOC set and tape and everything 
and that was supposedly because the first might maybe have had a problem with it and 
those two were the same. 

A. Is this a cluster environment? 

Q. No, stand alone 750. 

A. Were you a field test site for 4.6? 

Q. Field test for nothing. 

A. I’m sorry I don’t know what that is, I’d like to talk to you about it afterwards, if you catch 
me afterwards I’d.... The problem is new to me in the sense that if you replace the right 
file that the messages are correct, perhaps the version of backup is what we need to look 
at, but I’m pretty sure the message numbers didn’t change, Andy just suggested that. I’d 
like to address the other thing you mentioned though, and that was the your fear that if 
you got RMS journaling that you’d lose the journal. The design of journaling is such that 
that is the correct result. What backup does is exactly right in that it disables journaling 
on the output file and this the right thing to do and journaling is designed to help you and 
work with the backup copy if you should make the restore. 

Q. I guess my question comes, suppose I decide to compress my disk by running an image 
backup and restore will I also lose the journaling then? 
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A. At the moment in version 1 when you compress your disk you will have remark all the new 
files for journaling. 

Q. I hope that’s well documented for the people who have journaling. 

A. There’s a big note in the RMS journaling file and we will be looking at how to make that 
a little easier in the future release. 


Q. Tom Boutel, US Geological Survey. We’ve got a VAX 780 with a foreign UNIBUS periph¬ 
eral, it’s for a plotter and also has a foreign driver. We noticed that a short time within 
two to three days after we reboot the system the CSR address as reported by SYSGEN 
SHOW CONFIG increases by 4. I found this when I was investigating a little problem we 
had with paper run on, I still haven’t figured out if they’re related. And, you know the 
run on is not a real problem as it ends after about 400 feet of 36 [inch] wide paper, but.... 
I just need to get some idea whether this is a driver bug I should be looking for or you 
know, what I should be looking at. 

A. Is that the virtual address that it shows up in the SHOW CONFIG display that increases 
by 4 or is it the physical address? 

Q. Whenever it says CSR. 

A. Well, there’s two addresses, one is physical and the other one is virtual. 

Q. Not under.... 

A. Does the number start with 80 million. 

Q. No. 

A. No. So, it’s 76 or 77. 

Q. Right. 

A. Proctol, that’s the physical address. Just asked a question, does SHOW/UNIBUS show it 
as moved also? 

Q. I haven’t checked that. 

A. Because if it moved....All right I’m afraid you’ve stumped the panel, (applause).... About 
the only thing that comes to my mind is that you have either this device or some rouge 
peripheral which is responding incorrectly to the UNIBUS pole which is in turn causing 
all the other floating CSRs to shift. That’s about the only suggestion I can make. 

A. (from audience) Could I make a comment on the other one...He’s got a Versatek, it’s got 
two CSRs and it will show at differing place at differing times. 

Oh, no he stumped the panel....he didn’t stump the SIG Steering Committee, but he stumped 
the panel. 


Q. My name is Larry Kilgallen. VAX is a VAX, but unfortunately an Ethernet driver is not 
an Ethernet driver is not Ethernet driver. I’ve had considerable compatibility problems 
with the driver for the DEBNT or DEBNA or is there a new name this week. The problem 
relates to preallocated buffers. Now, developing this on a small machine and building up 
we found that there’s no problem, you can just specify preallocated buffers and you get 
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them, but in this particular driver under 4.4, 4.5 or so with the DEBNT there is a limit 
all of a sudden of 26 or so preallocated buffers which makes it very hard for someone to 
run varying products on the machine, either DEC or third party, all of which make use of 
these buffers. Then when the site in question converted to the DEBNA and then had to 
also upgrade the 4.6 and then field service had to come in an wave their hands over it and 
put in a patch driver and you know things that were related earlier, after than conversion 
the number buffers allowed to be preallocated was raised to 43 or something like that and 
they were told that was as much preallocation as was allowed in the driver because the 
hardware couldn’t take it any more. Why on earth is this a hardware issue. I understand 
that you can only give a certain amount to the device perhaps, but why can’t the driver 
hold onto them so that multiple products can work on one machine at the same time? 

A. Off hand I really don’t know the answer to that. It was my understanding and I’m not 
the data link driver but it certainly was my understanding that there was some sort of 
hardware limitation. Off hand I just can’t tell you what that is. 

Q. There’s a hard coded number in the original driver and if you look in the micro fiche it 
says this is a parameter which you might want to change on a per site basis, apparently 
the dual for changing is the patch utility which not, you know, and all this whole area is 
totally undocumented in the book on how to do QIO’s to Ethernet devices. 

A. Well, if that’s what the code says, you’re at your own risks in terms of altering that number. 

1 know that there were some more considerations than just software, I think it has to do 
with trying to not take...I mean, it has to take all that memory from you for non-page 
pool.... 

Q. Yeah, I have a parameter to jack that up. 

A. Right. I’ll talk to the developers again about the problem. You are aware that there’s 
another problem that’s fixed with releasing some of those buffers... There’s a few people 
who have reported to me that some of those buffers aren’t being released and there’s a 
phase coming in 4.7 for that. The symptom will be that when you open up the fifth 
protocol and open and close the fifth protocol on there a number of times eventually you’ll 
get either an insufficient virtual memory or no 10 channel and that’s a bug that’s being 
fixed. I’ve told a few people it’s fixed in 4.6, it really is fixed 4.7. 

Q. Is that only the fifth protocol or the fifth, sixth and seventh. 

A. Yeah, it’s only if it the fifth. The work around is to open a dummy fifth and then fool 
around with the sixth.... What most of the people are finding is that people are trying to 
do connect to COM, to use console carrier. It will turn out that to connect the ??? with 

2 protocol will be the fifth one and they’ll connect up and down a couple of times and all 
of a sudden they’ll get reported no 10 channel. So, on booting we should open up five 
dummy protocols so that when our users open up things asynchronously we don’t have to 
tell them you’re allowed... 

Q. If the fifth protocol is bouncing up and down, then open up a dummy fifth and then use 
the sixth until you get the path. 

A. Okay, thank you. That would be a great submission for the software dispatch. 


Q. Bruce Bower, General Electric. I first asked this question about two years ago and then 
a year and a half ago, so you’ve had plenty of time to think about it. I have a situation 
where I have a single tape drive, I have users who like to create tapes. Occasionally these 
tapes go to multiple volumes. For security reasons and various other reasons we degauss 
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all the scratch tapes. Let me make sure I’ve got all the facts right here. Can’t determine 
before hand that this user is going to go to a second tape or third tape or fourth tape and 
preinitializing tapes after they’re degaussed is not a viable alternative. How do I create 
that second or third or fourth volume. REPLY/INITIALIZE, and REPLY/ to both require 
the tape a valid label and REPLY/BLANKTAPE requires that the user who is creating 
the second tape has privilege, clearly I don’t want to give my users privilege. 

A. Is this using BACKUP or is this using some other.... 

Q. BACKUP handles it just fine, this is using for example COPY. 

A. We’ll eventually figure out who gets to answer this one. Certainly in my mind requiring 
privilege for REPLY/BLANK is wrong, because after all it’s the operator that’s taking 
that option and the operator is presumably is trustworthy, you know, to invoke the blank 
tape process in which ignores anything that might be on the tape, you understand the 
problems with trying to read a blank tape.... 

Q. Yes, I do and I certainly hope my operator is trustworthy, but that’s an entirely different 
issue.... 

A. Yeah, right separate problem. So, okay, we’ll I was handling this to Keith, he handed it 
back to me, Keith has been grubbing around in the magtape ACP lately. We’ll go back 
and have a look, if in fact, as we’re checking on user privilege it ought to get fixed and 
we’ll look into it. 


Q. Ken Robinson at Bellcore. I put this question on a NOTE[S] system at the exhibit hall 
and I’ll ask it here also. It’s a link question, I’m doing a build up of a software project 
product and we have a lot of executables and I’d like to get the same identification in 
version number and all these executables through the ident option in the link statement. 
I’d like to be able to do that globally so all the users don’t have to put this in their link 
statement and some may forget and some may do it wrong. I’d like to something like the 
link dollar op, link dollar options log or something that currently exist I haven’t found yet 
in link to let me do this. 

A. I about all we can say on that is noted thank you for your suggestion. 


Q. Keith Chatwick, Fermia Lab. Let me start off my question by asking the assorted panel 
if they participated or noted the events of the VAXfam cluster this morning from roughly 
8:15 to 8:30? Rather 9:15 to 9:30. 

A. There axe comments from the back row that many of the people were still sleeping, I and 
several other people were thoroughly aware of it, yes. 

Q. Yes. I am a system manager of a 4.5 Cl base cluster and a 4.6 LAVC cluster and have 
heard that 4.7 has gone to software distribution and I’m wondering what my exposure is 
on this particular hole. 

A. Okay. People want to know what happened, a trivial FORTRAN can crash the system 
and that’s all I’m going to tell you. DEC is not terribly well set up to do emergency 
distribution of patches for killer problems like this. I am not the person to answer that 
question. There is a corporate task force that’s working on that problem. You can rest 
assured that the spring security problem got the corporations attention in a real big way 
and unfortunately when you have a 10 billion dollar company with 100,000 sites, things 
like this don’t get solved over night. The answer is, we’re working on it and I believe you 
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can expect some kind of reasonable solution. I can’t make any promises about when or 
exactly what they’ll be. 

Q. Could it at least, can you at least answer the question as if the problem exist in earlier 
versions or don’t you know that. 

A. Our terminal driver maintainer says it’s probably been there a while. 

Q. When’s it fixed? 

A. It’s not. Let me just make one more comment. Obviously when we get back to Nashua 
next week, I am sure Forrest is going to sit down and you know poke this one out and 
we should have a patch to correct the problem in a very short period of time. The big 
problem is always is making the patch available to the customers. What we’ve done is 
as soon as we have a patch for a killer like this we make it available to the CSC and you 
know, unfortunately that’s the extent of what we in software engineering can do about the 
problem. 

Q. Excuse me a quick comment on that. Could you at least make it so that the folks at CSC 
would make it on line so we can pull it off. 

A. We can certainly make that suggestion to them. 


Q. Okay, this is Ken Barons from Rockwell International. Here’s my question. It has to do 
with a VAXstations, VAXstation software, the problem comes up when I have between 
forty, actually between thirty and forty windows on the screen, about half of them display 
in data at once. Everything freezes. The cursor no longer tracks the mouse, nothing 
happens. I guess I should tell you it’s a VAXstation 100, I am running version 1.2 and I 
was wondering if there is a newer version of the VS 100 software and I’ve also got some 
other symptoms. The symbiont process that is controlling this VAXstation does go away, 
there’s no notification of it and I can’t start another one because it says it’s there. 

A. Okay, unfortunately I’m afraid we’re not going to be able to help you on that one....oh, I’m 
sorry. I’m told there is someone in the audience who is willing to deal with this. There’s 
a person over there who’s shaking his head. The VAXstation 100 software is produced by 
an organization in DEC other than us VMS development, so nobody up here can tell you 
a whole lot about it. My apologies. 

Q. Is it true that the softwares no longer supported? 

A. That’s an obsolete project. I believe if you check there should have been a letter sent to all 
supported sites at least a year ago that I remember announcing the status of that product. 
It is not true that the VS 100 software is no longer supported, but it is true that the VS 
100 software is no longer supported by the VMS organization. The software now resides 
is my understanding with our software services organization and they are responsible for 
all maintenance and updates to the software or fixing anything that goes wrong. 

Q. Colorado or Atlanta know nothing about it. 

A. Right. It is handled at a corporate level for VS 100 customers, but it the responsibility of 
the software services organization. 

Q. So, the bugs might be fixed? 

A. The bugs could be fixed. I’m sorry there is not a definite answer we can give to that one 
because it is not the VMS product. 
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Q. Pete Sevy, Dow Chemical. This ought to be a quick and easy one, because I asked it a year 
ago in San Francisco and I just want some clarification of it. Support for RX02s and their 
actual Q-bus controller on Micro VAXes and VMS version whatever it is in the future. Is 
it going to be there? 

A. We have no plans to support RX02s on Q-bus. 

Q. How about if it happens to work on the UNIBUS can we move over the driver like we did 
before? 

A. For us to support a device it has to go through a number of testing processes and quali¬ 
fication and diagnostics have be written for it and all kinds of things to that effect. ???? 
you won’t see us very often pick up an older device and support it on a bus that’s new 
to the VAX family. That doesn’t say that if you didn’t try it might not work, we don’t 
know, we haven’t tried it, we don’t use those, so your guess is as good mine. Q-bus and 
UNIBUS are very similar. There’s probably a good chance it might work, but it wouldn’t 
be supported. 


Q. I’m Earl Kates from Lockheed Missile and Space Company, I need to know whether I will 
write an SPR or contact software services to get VMS to run on my VAX. I have a 782? 

A. Are you talking today or in the future? 

Q. Future. 

A. We have some upgrade programs in place. Your sales rep should have talked to you about 
this, if he hasn’t, if you’ll give me your name I can pursue this and talk to you about it off 
line. 

Q. Okay, because he told us that 782 would be supported and I thought I’d better ask. 

A. In point of fact the 782 will not be supported in the future major unannounced release. 
So, if we can discuss this off line I’d be glad to do that. 


Q. I’m David Kathy from Texas Instruments. First I would like to give kind of a bit of an 
answer for the guy that’s wanting to do the SET TERMINAL on a virtual device or a 
templet device. What we have done is gone into SYSGEN, modify the DEV_DEPEND 
and DEVJDEPEND2 and then connect the device and then change the Dev depend, dev 
depend to back to what we wanted it for. So, when you do the connect to the templet 
device it will pick up a new set of parameters rather than the current default. Now, for 
my question, I have a modified print symbiont. The modified symbiont has to do some of 
that little extra work when it starts up and I’m going into the start task for the output 
routine. In order to start that up it’s going to take a, maybe, a somewhat lengthy point 
of time. I need to pass a PSM$ pending, so in order I can run multi stream, otherwise I’m 
forced to just go through a single stream in order to maintain what I’m doing otherwise I 
might get a stalled queue on one and everything else would stall also. I was wondering if 
you’re planning on any kind, if there’s any kind of support or ideas. 

A. I’m not that familiar with the internal of the symbiont, but I’d be happy to talk with you 
afterwards and take it back to our symbiont developer. 
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Q. Gregg Avery, this is also symbiont question, but a little bit simpler I hope. We have a 
couple of different sites and at one of the other sites the guy there has an LN03 plus and 
we also have a laser printer, laser jet, both of us experience blank pages printing out at the 
beginning. When he called up tech support after talking to a couple of different people, 
they said yeah, we know about problem the fix is put a form feed in your reset module, 
by adding that form feed you’ll actually get rid of the extra blank page. He did that and 
it worked, I did it and it didn’t work for the laser jet, what’s really going with these extra 
form feeds and why does it work on the DEC printer and not on the HP printer? 

A. Gee, I really don’t know. Again, why don’t you see me afterwards, I’ll get the details down 
and maybe we can have our symbiont developer get an answer back to you. 


Q. Bill Wiespone with Schlumberger Well Services in Dallas. First I get a kind of a comment 
as I was standing in line here I hear about this possible security bug feature whatever 
that may or may not crash my VAX, but because DEC is unable, unwilling or whatever 
to figure out a way to discuss security problems I now have to go back to my boss and tell 
him that my sixty five machines may or may not be subjected to a security hole, but I’ve 
got no way of finding out what that hole is, is whether or not I’m exposed, not exposed 
and I think it’s about time that DEC do something to figure out some kind of way to talk 
about and/or disseminate security information to the registered VMS users. 

A. Right. Please understand. I fully sympathize with you. Please understand that among 
those registered VMS users are very likely the hackers that are trying to break into your 
system... 

Q. I disagree with that.... 

A. What’s going to happen... Believe me there are. 

Q. ???? the question we keep tapping dancing around it, but let me get on to my question. I 
know it’s not the form I just felt that that needed to be brought up. 

A. As Andy eluded to earlier, we do in fact have a corporate task force working on this 
problem. We have representation from our legal people, from our manufacturing people 
who distribute the patch, from engineering, from all the appropriate groups. We are 
concerned. This is a serious problem. It’s become much more serious now that we have 
networks that convey information much more rapidly than was the case a few years ago 
when it was paper only. So, we are not ignoring this problem, but it is a very very difficult 
problem to solve and it’s going to take some time and some work on a lot of people to 
solve it. 

Q. Right and I understand that. All right my question is somewhat relatively simple, maybe 
and that is dealing special SYSGEN parameters. Now, surely somewhere, somehow those 
are documented someplace and every now and then I need to know what a particular 
parameter is and what it does and they’re not covered in the regular SYSGEN manual. 
Are there any plans to document these, ever? 

A. In general one of the primary reason the SYSGEN parameter ends up being special is that 
its usage, the semantics of its usage or if it bit and coded etc., are all subject to change. 
Okay, now if we document that, that’s as much as committing to that interface and we’re 
not about to do that for some of those parameters. Now, the argument that you might 
make and it’s a valid one is that some of those parameters that are tried and true and 
well understood might very well either be eliminated or be put into the non special class, 
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but special SYSGEN parameters by their very nature are meant to be undocumented in 
general. 

Q. Okay, but also by their very nature they critically affect the operation of your machine and 
if you get yourself in a situation where your machine is crashing because you have too small 
a SLI symbol table or a PIO pages, for example and you have no idea what’s going on, 
you don’t have anywhere to turn to and I think that from a system managers standpoint, 
anything that affects the operation of the machine should be documented someplace and 
if you don’t want us to touch it, just put do not touch on it. 

A. Okay, it sounds like the type of parameters you’re describing are, in fact, either should 
be removed or should be fully documented because if you have to tweak them on a fairly 
regular basis in order to achieve performance goals, system management objectives or 
whatever, then by their very nature they should be documented and they shouldn’t be 
special and I think you have a legitimate beef that you should make to the SPR mechanism. 

Q. Okay, even if they’re not regularly tweaked, it only has to happen once. 

A. I would comment that several SYSGEN parameters are better documented in the on-line 
SYSGEN help, than they are in the manuals. 


Q. David Swain, Auburn University. We have a problem with disk quotas that’s been around 
for awhile and people will have just a few files in their account and suddenly the operating 
system says their disk quota is full and you can rebuild a disk and it fix it and....last Spring 
in Nashville this was brought up and we were told you all were looking at it so...what’s 
the news. 

A. We’re looking at it. It’s not something that we can reproduce in our lab with any degree 
of reliability or certainty. When it does happen we can’t detect or predict where it’s going 
to happen from. 

Q. So, it has happened in the lab, though? 

A. We have seen it, yes. We’ve seen it happen, but unfortunately when it happens, when 
we’re looking to the right it happens on the left or behind us. But, we are pursuing the 
problem, we haven’t given up on it. 


Q. Jim Neilings, Hughes Research. I have a VAXstation II/GPX and normally using that 
stand alone if I do a SYSGEN CONNECT CONSOLE I get access to CSAO which is 
printer....what I’m using as printer port....serial port. If I use that same machine in LAVC 
SYSGEN CONNECT CONSOLE basically does nothing. Is there some way that I can in 
fact get to that serial port? 

A. You’re unable to get to the console serial port? 

Q. That’s correct. If I do the SYSGEN CONNECT CONSOLE I get no error message, but 
then if I try to do something to CSAO, it says no such device. 

A. Does it show device show CS....show the device? 

Q. No. 

A. Unless somebody here has an answer I guess you’ve stumped the panel again. When you 
do a show device can find an OPAO? 
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Q. Device type OPAO or device name OPAO on that system, Pm not sure. 

A. Do you find the CSAl then? 

Q. No. 

A. And, you don’t find and OPAO or haven’t you looked for it? 

Q. I don’t remember looking for OPAO there. 

A. Pm sure why it would be doing that, but it’s possible that it’s leaving the ????? loaded 
for that device and treating it as the output device. And, look for that and see if it helps. 


Q. Allen Frisbee. I have a Micro VAX II with a pair of RX33s and I discovered that I cannot 
format them, if I use the INIT/DENSITY=DOUBLE switch, I get an error message saying 
invalid 10 function code. However, it works just fine on my friends MicroVAX 2000. 

A. We are expecting to support the RX33 on MicroVAX II in the next major release. 

Q. Well, yes...but it’s currently in the systems and options catalog, I paid out good money 
for it and now Pm stuck with something that won’t format. 

A. We had to do an ECO to the MSCP architecture in order for us to provide a way to get that 
function through our MSCP drivers off to the RQDX3 controller. Since the VAXstation 
2000 has an RX33 sitting on a different kind of bus, a different kind of interface, we were 
able to offer that capability in the first release of the VAXstation 2000, MicroVAX 2000, 
but we couldn’t get it into the Q-bus I without an ECO 2, essentially the whole and the 
CP protocol. Therefore, it’s taken us a little longer to get there and you’ll just have to 
wait a little while longer and we’re sorry about that. You can format those floppies with 
diagnostic and I realize that’s unfortunate that you have to go stand alone to do that, to 
run the diagnostics, but we’re fixing that as fast as we could, it just took us longer. 

Q. Unfortunately the diagnostics you refer to are only available to field service, not to cus¬ 
tomers. So, Pm stuck again and your sales force is selling these. So, what’s an interim 
solution? 

A. There is no other solution right now. We’re sorry about that, we put it in as fast as we 
could, it will be there in the next release. 

Q. If I sent you a box of floppies, will you format them for me? 

A. What do I get. 


Q. Dennis Costello, Cornell University. I have a lot of users who are fairly naive, maybe I 
am too on this point. They like to run long batch jobs and they might be writing to files, 
they look or just sequential write files, nothing very exciting, it’s all from FORTRAN...The 
thing is since the job tends to run for days they would like to be able to look at the file 
periodically and inspect it and see how the jobs going. Now, obviously they could do this 
the same that you do the log file, close it, open it for a pen periodically, but if they didn’t 
do that is there anyway that you can look at such a file, just type it out, look at what it 
says even if the last few records aren’t correct? 

A. Okay, well the answer is if you open the file with FORTRAN, you say, ACCESS=SHARED, 
then the current version of RMS will in fact track the end of file correctly. The TYPE 
utility in particular does open the file shared, TYPE will type a log file that’s currently 
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open for write, so I believe you can do what you want. It doesn’t involve any special 
commands. 

Q. Yeah, that works for the log file, but to write the log file the FORTRAN parameter will 
just write to SYS$OUTPUT or whatever, but if they’re writing to an explicitly opened 
file? 

A. We had somewhat the same problem and the solution we used was to use the FORTRAN 
open specifying shared and then periodically call the RMS SYS$FLUSH routine to write 
out any records that were buffered and we used the mechanism that’s in place for getting 
the FAB address from the FORTRAN run time system to call the RMS routine. 

Q. Okay. These....all the wrong way of looking at it. All that requires that you make changes 
to the programmer that’s writing this. I want to have something that’s completely written 
completely naively and then I want to just look at the file without getting this. 

A. You could probably write a utility that opens the file specifying user provided interlock 
and that’s completely overrides all RMS locking and you just open the file and dump it 
out. 

Q. Okay, I’ll try that. 


Q. Phil Knecett, Consultant. I have a problem with VMS running VWS 3.1 on a monochrome 
workstation. I have a compute bound process in one window, updates to the other windows 
go exceedingly slow. I’ve talked a number of other VWS users and they see the same 
behavior. Now, on the surface it would seen that at best I...for example I’m running a link 
or a compiler or something that’s really eating CPU and the other window or in might 
not even be in a window for that matter and... it seems that at best, at worst I should 
get 1 over N or the CPU to do my updates and I should go perhaps half as fast. Indeed 
I think I would get better because I should be getting a scheduler priority boost because 
the VWS driver I hope is doing 10 and getting me that boost. Any ideas why updates are 
slowed down so much when I have a compute down process on a workstation? I mean it 
goes down by a factor of 10 or more. 

A. I’m sorry but it appears that we don’t have any VWS expertise here on the panel to help 
you. 

Q. I talked to the VWS people in the booth at least and none of them had any idea, they all 
thought it was your fault, so. 

A. Question for you. Is the workstation a GPX or a VAXstation? 

Q. No, Monochrome, QVSS, you know, old flavor.... 

A. A QVSS? 

Q. Right...QVSS...Monochrome. 

A. Okay, I can address part of the question. You did ask about the priority boost. Now, there 
is a minor hitch here in that because the VWS driver operates within the process context 
there is no actual wait for that’s executed by the process to wait for the 10, unfortunately 
the priority boost is tied right into the wait for mechanism, therefore in fact, you do not 
get the priority boost. There’s not a whole lot that I can say about your performance being 
apparently worst then 1 over N, unless in fact it turns out you are doing say, something 
like a compile or a link which is in fact doing disk 10 which giving it a priority boost and 
is therefore in fact making the apparently compute down job somewhat higher an effective 
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priority than the job that’s updating the window. 

Q. Good, so what I need to do is dittle what parameter in order to make that be delayed 
longer until it gets the priority boost. I want the scheduler to wait longer to give it the 
priority boost. 

Q. Now, unfortunately the priority boost is given on each 10 and wait for. About the only 
thing that you could do which is not particularly supported would be to find the priority 
boost table in SCHED and patch it, because the different types of wait fors are done with 
a class number, there’s a little table in there that’s indexed by class that has the actual 
boost values. 

A. I think that explains my observed behavior anyway. Thank you. 


Q. Dave Cooke, Maxi Care Corporation. We have a problem with RMS. We’re using shared 
sequential files open for access in all modes. One thing I might mention is we’re using 
version 4.5 of VMS. We’ve tried installing the 4.6 RMS EXEC and we still see the problem. 
What appears to be going is are occasionally some processes we may have as many as say 
twenty or thirty processes opening this file simultaneously and at some point we make 
a request that all these processes close the file, we find a situation where one or more 
processes will close the file but they still retain their internal channel to the file. When 
they reopen the new file they get a new channel to file and that channel is subsequently 
used for all the 10. The old channel remains, but no further activity takes place on it. The 
only way that the channel is ever released is when the process finally terminates. Do you 
have any suggestions? 

A. We haven’t heard of this problem. It’s a new problem that you should definitely SPR. 
If you feel like digging in with analyze system a little bit yourself, have a look at the 
process, have a look at the apparently dangling channel, see if the 10 count is zero, that 
is, you know, see...do a SHOW PROCESS/CHANNEL, see if it’s marked busy, if there 
are any IOs outstanding, is there a deaccess pending on it, that sort of thing. Any sort of 
diagnostic information like that would be useful. 


Q. Bob Lanford, the Medical College of Virginia I would like to know how the terminal 
numbers, type numbers and names are determined. For instance, if just SET TERMI¬ 
NAL/INQUIRE it figures what kind of terminal you are and if you’re working with the 
SMG routines, it seems to know and it even has a name for it, but there’s not document 
correspondence between the integers stored in the unit control block I believe it is and the 
names. It seems to be adjustable or it seems to work, but I don’t know how to predict 
what numbers will be given. 

A. There’s two parts. The first one is how does it determine, there’s a known set of who are 
you sequences the set turn runs through to ask the terminal who axe you, literally who 
are you and looks for set responses back and it will run the table and if you happen to 
get a device that requires that you go to the end of the table, it will take a little while 
to complete. The second half is that there’s a definition it’s TTY DAS which contains 
the device type and the device name string for VMS supported terminals. For foreign 
terminals, for SMG, that’s handled a little differently and I can’t give you the exact details 
of how SMG does it. 

Q. Is there anyone there that who can? It doesn’t seem to be documented. 

A. For SMG for the foreign terminals, the numbers are known because they’re negative where 
the Digital supply terminals are positive. There’s nothing, no specific allocation scheme, 
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they’re just allocated in ascending or descending order and as it find it when it’s processing 
turn table when you can define your terminal. Okay? 

Q. How does it know which, I mean, all the DEC terminals axe defined in the SMG term 
table as well, but I haven’t seen anything that says this one’s getting a positive number 
this one’s going to get a negative number. 

A. Well, we know it’s a DEC terminal, we supply the definition. 

Q. But it’s in the same file that I put my definitions in. I mean maybe, you know, that’s not 
a good way to do it, how does the SMG term table compiler recognize, does it just have a 
list of all the names that are DEC names? 

A. Actually I believe it does. I believe it uses the same list that Forrest was talking about for 
all the Digital terminals. 

Q. I see, so it sort of ignores the device replys....? 

A. Yes. When SMG starts up, we actually do a ?? DVI and we find out from the terminal 
driver or sense motor which ever one it is, I don’t recall off hand. 


Q. Vince Televeris, Script Corporation. At the, one of the shadowing disk talks, it was 
mentioned that there’s special considerations for running shadow, using, shadowing your 
system disk. And I was wondering if anyone up there could tell me what they are? 

A. What particular special considerations are you referring to? 

Q. Well, I think it was something in, with respect to stand alone backup. 

A. There’s special considerations for booting the system disk off of shadow sets. You specify 
in one of the registers to VMB two different units numbers when you booting off of a 
shadow set, one is the virtual unit number of the shadow set and it’s denoted by the sign 
bit being on. The other is a single member of the shadow set which is the disk that you’ll 
boot off of if the virtual unit is not created when you’re booting and you want to make 
sure that all systems in the cluster specify the same physical member to be the default one 
that you boot from if there is not a virtual unit created when the system is booting. 


Q. Steve Wright from ???? Software in Virginia. We support a bunch of sites and regular 
780s, 785 type VAXes and a fair number of MicroVAXes, we’re having trouble getting 
AUTOGEN to configure VMS images the way we want in configured and aside from going 
into the start up and deinstalling and reinstalling raffs of layered products, I’m wondering 
if there’s anything wrong with it, if you know what you’re doing. Editing that file, then 
converting it back to its original format which we get for analyzing it. 

A. Back to its original format, could you describe what you mean by that? 

Q. Well, you do an ANALYZE/RMS/FDL which saves its format, its block span and it has 
a couple of other attributes that we’re not sure if there’s something that relies on those 
attributes and then we edit the file. It creates an output file that’s a different format and 
we convert it back to the original format. 

A. VMSIMAGES.DAT is just a sequential file, certainly editing that file is something that 
can be done in any editor, but is, you know, certainly we can’t support that function. I 
will tell you that AUTOGEN will recreate that file each time that it’s executed so bearing 
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that in mind, you know, you’re on your own there, but it’s.... 

Q. I guess what it boils down to is, is there anyway to make AUTOGEN create the file 
correctly? No necessarily for the layered products but for the stuff that comes with VMS. 
PHONE for example, we can’t get it to install PHONE. I mean, it would nice to use 
PHONE on a Micro VAX with thirty users. 

A. There are two versions of, okay, that brings up the different issue. Two versions of VM- 
SIMAGES.DAT, in quote, big VMS AUTOGEN creates that file, in Micro VMS that file 
is not created by AUTOGEN but ships with the kit. In an attempt to minimize memory 
consumption by the installed image list and if there is sufficient memory then those steps 
that we talked about earlier might be appropriate for your site. That is not created by 
AUTOGEN in Micro VMS. 

Q. Would there be anything wrong with taking a 16 meg VMSIMAGE.DAT from a 780 and 
putting it on a MicroVAX II, with 16 meg? 

A. Micro VMS due to the kitting procedures and perhaps if you have tailored all files may 
not find files that are in that file and hence at boot time you would see, you know, rather 
nasty error messages. 


Q. Keith Carston from Data Quest. The problem I’ve been having is with an ISAM file. It 
has a primary key and alternate key, the alternate key has embedded in it the primary 
key and I’ve got about ten thousand records, about a six to eight thousand block file and 
what I do for the particular application that I’m using it for, I pull in a set of records, the 
particular example I’ve been working is 116, play around with the alternate keys, the non 
primary key portion of the alternate key and then write those, rewrite those records back 
and if I do that after a series of times the index buffers wind up or the index buckets wind 
up getting messed up and when I pull in records again the same 116 records, instead of 
getting 116 records I’ll a hundred and ten or a hundred and twelve. I’ll redo the indexes, 
write them back, pull them back in and all of a sudden I’ve got 116 again and if I do that 
a couple of times it winds up corrupting the ISAM file. This is an outstanding question 
and they did suggest that I turn off...I had no duplicates on both the primary and the 
alternate key, they suggested that I change the no duplicates to duplicates allowed on the 
alternate key even though that’s impossible and we’re arguing over that one right now, 
but you shead any light on this problem? 

A. When you, first of all which version of VMS are you running? 

Q. 4.6... 

A. And, when you mess around with the alternate keys are you in fact creating any duplicates? 

Q. It’s impossible, I’m not modifying the primary key, so there are no duplicates. I am 
creating....what I am creating is...let’s say I have one...I have one field and in the alternate 
key and then thats followed immediately by the primary key to make the whole alternate 
key, so field A and then the alternate key. So, what I do is I tweak field A and field A may 
either have a unique value across the whole data base or it may have a duplicate, but it 
won’t cause a duplicate key simply because the primary key is in there and is unique. 

A. Well, any time you get crock file doing normal operations RMS that’s a bug. I would 
definitely SPR that, so that we’ll see it. 
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Q. A1 Metzsinger, Eastman Kokak Company. Is it true that automatic....that the SYSGEN 
parameter of automatic centered increment, not increment, adjustment has to be an even 
multiple of quantum and can’t be below quantum? 

A. Yes, it does and the reason is that the automatic working set adjustment mechanism is 
triggered at quantum end events and therefore you have go through a quantum end event 
in order to have automatic working set adjustment happen and so therefore, it makes sense 
to have it be a multiple, ???? a quantum. 


Q. Dennis Costello, Cornell University, again. We would like to be able to do things like SET 
HOST DTE/LOG to a terminal server port, has a modem on it and the modem is set 
both incoming and outgoing and therefore it is declared as a service and we can connect to 
the service through the terminal server and use it as outgoing modem, we can dial in and 
connect to wherever we want, but the one thing we can’t do is SET HOST DTE/LOG and 
that will very handy sometimes. Alternatively, if the current developer is in the room and 
wants to do the programmatic interface for ???? connect to give me the same functionality 
that would help, but I’d like to have the same kinds of functionality that I had when I had 
the modem or a PC or any other kind of device like that attached to a hard wired port 
that I do in the terminal servers. 

A. Yeah, we’ve had that request from a number of people and we’re working on it providing 
the capability for set host DTE won’t be coming real quickly, but it will be in the future. 
An application program that what’s to do similar things has a mechanism in 4.6 to connect 
to a terminal server port and.... 

Q. Yeah, the QIO call, what I think it was a poor choice because it broke a lot of code and it 
broke a [tape skipped here]....to fix. 

A. It didn’t actually break the code, it just added new things that you should...[couldn’t do]... 
the code that you have control of. 

Q. Right, but it cost me a lot of functionality there, that I haven’t been able to get back. I 
call that a break. 

A. Okay, it’s as noted. 


Q. Glen Zorin, from ADP. I’ve been setting up a DECnet asynchronous DECnet link through 
a DZ32. I’ve been able to get it to work through the DZ11 and DMF32, but the problem 
with the DZ32 is it comes up, it runs, everythings fine and dandy, but I dissolve the link 
in the channels the port on the DZ32 hangs forever. The only way to get it back is to 
reboot the system and I’ve had field service in, they say it’s software, they’ve softed out 
my board, they’ve run diagnostics, I’ve called Colorado support and they say, it must be 
the hardware. The only other side affect I got is on the DZ32 when I do the set terminal, 
every port on the DZ32 gets an error count of one, but if I do a set terminal a second on 
that port after booting the system I do not get an increase of error count on that port, but 
I can run terminals in and out of that port, in and out of those ports no problems and I 
was wondering if maybe you have some insight on what is going on with me. I’m running 
4.5 of VMS currently. 

A. No, off hand I don’t have any insight. All I can do is say, have you SPR’d the problem? 

Q. I called Colorado support, but I haven’t SPR’d it, but they just saying it’s hardware call 
field service. 
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A. It sounds like software to me and perhaps at 4.5 there could have been a problem. There 
were a number of fixes in 4.6, so I think that the first thing you should do is try to get up 
to 4.6. 

Q. I have to wait till 4.7 is released. 

A. Okay. 


Q. I’m Tim Mahany, I’m with DGM Sz S. About five or six months ago I sent a sample of 
an extremely trivial file to Colorado which would cause the print symbiont to go into kind 
of random block selection mode for printing. I got, I actually got a phone call relatively 
quickly from Colorado. The representative didn’t believe me and submitted it and said by 
the time he got to the machine room there was paper all over the floor. I was wondering if 
someone could give me any kind of hope as to when that might be fixed? It’s reproducible 
and I think it’s either a three or four byte file that will do it. 

A. I don’t know if it’s your file or not, but I seem to recall seeing an SPR that our printer 
symbiont person is working on. You see, I don’t know specifically if it’s your problem, but 
we have something that’s similar to that description. 

Q. Colorado said it was submitted to engineering, I didn’t know whether that was the garbage 
can or what, you know. 

A. Yes....I believe we’re working on it, but I don’t know the status of it. I seem to recall 
seeing something like that on our problem list. 


Q. John Chambers, Naval Avionics Center. I’m here asking this question on behalf of a 
manager at our site who is unable to be there. They’re running a 785 stand alone system 
on a version 4.5, got their system disk on an RM05, they cart the system disk over to 
RA81, the DUA’s magically become DUB’s, nobody seems to know why. They put it 
back on the RM05, they magically become DUA’s again. By the way we have third party 
maintenance and they’re pointing the software and when we call software they’re pointing 
to the hardware. 

A. I had the same problem. I was trying to convert a Cl cluster to a couple of boot members 
for an LAVC, we’re not sure why the VMS decides when you try to boot up the UDA that 
it wants to make that device blink, because we had the same thing we had been booting 
out through the Cl and they had been coming saying, “B” correctly. There is the upper 
byte of R5, if you put a 1 in there it make it controller A, if you put a 0 in the upper byte 
it will determine it itself. If you put a 1 in there it will make it controller A or if you make 
a two it will make D and so on. So, that will fix your problem. 


Q. Mark ????, ?????, Denver. I have an LAVC with twenty nodes running VMS 4.6, all nodes 
are running queue manager using the same JBC ???? dot to the ???, the same job queue 
file, when one of the nodes shuts down using regular shut down, in about fifty percent cases 
the whole job queue system, ???? for the whole. When the node comes back, immediately 
when it gets the connection to the other nodes, the job queue systems magically restart 
itself. I assume originally that the shut process doesn’t give queue manager time enough 
to do all the clean up and that the it kills the queue manager before finishes up, so I 
went into my systems, not my...???? shut down procedure, stopped the queue manager, 
explicitly gave it two minutes to wait before...shut down to continue, the situation seems 
to be approximately the same about fifty percent of time I get the job queue system host. 
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The solution is to go boot that node immediately back or boot another node immediately 
and try it again, shutting down, but my users don’t like transitions too much. 

A. I’m not sure I understood all of your question. Are you saying this problem occurs when 
one of the nodes in the cluster goes down. 

Q. Then the node is regularly shut down with the remove under a node option. 

A. Okay. I think I’d like to talk to you afterwards. I would like to make a comment, however, 
on the case where a node in the cluster exits and in which case the connection manager 
notifies all the job controllers that a node has gone away and they all attempt to access 
the queue file to clean up the queue’s for the node that just went down and this level of 
redundancy, especially in a local area cluster where you may, you know, have twenty nodes 
becomes a very time consuming and expensive operation. In 4.7 we have modified this 
algorithm to make it much much faster, but that’s not addressing your problem but I just 
wanted to make that comment since it was.... 

Q. Is there a hope that the ???? let it wait five minutes that it will fix the program? 

A. Possibly. It depends upon the number of queues, the number of jobs in the queues managed 
by the node that you are shutting down to determine how that might take. A stop to 
manager operation can take quite a long time if there are lots of jobs that have to be dealt 
with in those queues. Where lots may be, you know, fifty or hundred something of that 
order. 


Q. Stan Rhodes from Bankers Trust. This is in a lighter vein, prompted by the fact that we’re 
coming into Leap Year. I would like to see a republication of the SPR, a very thorough 
SPR that was read about two, maybe it’s two or three years ago at this point, explaining 
the reason that VMS handles Leap Year the way it does out about 800 years. It was a, it 
was very funny and I’d like to see it submitted to the page swapper which it never was. I 
think everyone would appreciate seeing that. 

A. Okay, thanks. Thanks for the comment. We’ll have to see if we can dig up a copy of that. 
I know which SPR you’re talking about. 


Q. My names Larry Fulgalone, as a side comment, I certainly understand that corporate com¬ 
mittee working on how to distribute security patches may be important, but I’m dismayed 
that the proposed interim procedure entirely cuts out those who are paying monthly for 
software self maintenance. My question has to do with a problem where I got egg on my 
face in a mixed vendor situation by saying, security oh, sure VMS can do security. The 
people wanted to let the communications department set parameters on all the terminal 
lines willy/nilly for political reasons and I thought that the way I set permanent parameters 
on a terminal is by giving myself logical 10 or physical 10 privilege and I knew that device 
protections instead of having categories of read, write, execute and delete, had categories 
of read, write, to logical and physical, so it seemed reasonable to me that if I protected 
a given device giving a particular group of communications people logical and physical 
access to that device in the protection then they would be able to set the characteristics 
on the terminal using the SET TERMINAL/PERMANENT command. I found out that 
this does not work. Apparently the SET TERMINAL/PERMANENT code specifically 
checks for the privilege rather than calling the check PRO system service to check for the 
protection. Is there any particular reason why this is done that way? 

A. Larry, I think the answer is no. There’s no particular reason. A lot of these things have 
been added on as VMS has grown and we haven’t always had the time to go back and 
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make everything consistent. I’d consider that a loose end that we ought to look at. 


Q. Dennis Costello, Cornell University. I’ll apologize if this is the wrong forum, but I haven’t 
the faintest idea where else to bring it up and nobody on the [exhibit] floor wanted to touch 
it. You have a lot of interesting text processing, things like RUNOFF and TeX and so on 
at your disposal, all of which will generate change bars, please use them for the SPD’s. 
The documentation people said that it was the individual product mangers that had to 
make that decision and I claim that that is corporate wide and I know who to tell it to. 

A. We’ll go back, we’ll talk to SPD administration, we use them internally, we know they’re 
helpful, we’ll see what we can do. 


Q. Phil Knecker. Dynamic asynchronous DECnet between V 4.5 and V 4.6 systems, I’ve 
been doing it in 4.5 and earlier systems for a very long time connecting to, oh, probably 
connect to a dozen different systems from my VAXstation and it works fine, after you 
get through all of the, every single thing that you have of course to get the net circuit 
up, but I... connecting to a 4.6 system just a couple of weeks ago, the circuit came up 
finally, but routing updates never occurred and I could never see his node from mine. I 
was up/down to him. I established the original connection and did the switch on his SET 
TERMINAL/switch on his node to get the connection back. Eventually the circuit did 
come up, but I never got routing connections, any idea? 

A. Yeah, that’s the second time in this DECUS that I’ve heard that. Now, I know in 4.7 
there’s some patches for some the async DECnet. So, I’m going to go back and look to 
make sure that we understand what that problem is. It sounds, at least, two sources that 
it should be fairly easy to be reproducible. So, we’ll get back and see if it’s in 4.7, I’m 
pretty sure there are some changes there. 

Q. As an interim patch that we’ve made work you can set the routing broadcast timer on the 
4.6 node to a reasonably short time, like maybe a minute, and then after a minute it will 
blow out the routing data and everything will come up. It’s like ten minutes normally. 

A. Another thing I heard someone say, the other person who complained about this, was just 
alter any parameter on the circuit, alter costs, okay... 

Q. Right. I tried both of those things. I set the routing update timer from 600 which is the 
twelfth down to sixty, didn’t do it. I tried various things that I thought would cause a 
routing update to occur and those didn’t do it either. As in a site, I’ve since connected to 
another 4.6 system successfully. So, I’m not sure it’s a 4.5 versus 4.6 problem either. 

A. We’ll keep that in mind when we’re looking at it. 


Q. Steve ????, Wizard Software again. We’re having a situation where we need to dismount 
a disk, here or there, on multi disks systems and forget to deinstall an image that’s on the 
disk, when the disk comes up as mounted, disk mount on a SHOW DEV D, we then go in 
an deinstall the image and the disk doesn’t finish its disk mount. Is that a bug or are we 
doing something wrong? 

A. Okay, we’ll have to take that back. I mean, certainly that should work from what you’ve 
said. I don’t see that you’re doing anything wrong. So, we’ll have to look and see what’s 
happening there. 
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Q. Ken Brown, Aptech Systems. I recently had an opportunity or reason to prevent AUTO 
CONFIGURE from configuring the first UDA50 on a VAXcluster and it configured anyway. 
I put in an explicit SYSGEN AUTO CONFIGURE/EXCLUDE=PUA in the SYCON- 
FIG.COM, but before it got there the disk had already configured. Is there a way? We 
weren’t booting from it, we were not booting from it. 

A. I’m sorry I missed the very beginning of the question. What, okay, what kind of machine 
is it and what are you booting on. 

Q. I believe it was a 780, we were booting off an HSC. It was not booting off that UDA. It 
was an RA80, I think on there. 

A. Yes. We think that what’s happening to you is that the configure process who’s job it is to 
find new DSA disk controllers is finding...is finding your UDA and believe that the configure 
process is independent of how you have auto configured the system. That is having done 
the....having told the AUTO CONFIGURE ALL not to configure the particular device 
does not tell that same information to the configure process and it will wait or find it and 
that’s what you’re seeing. 

Q. Well, I put a write line, you know, essentially a write to sys output in SYCONFIG.COM 
and the disk watching the lights on the UDA50 it had already initialized before I got the 
write line, significantly before. Now I can cause a UDA50 to be excluded if it’s the second 
one on a non cluster and I’m not sure which of those factors is the factor here. 

A. Which one can you exclude in the non cluster case? 

Q. The second UDA50. The problem was the first UDA50 on a cluster, on this node of a 
cluster. It was a local, wasn’t served. 

A. We’ll take that back and look at it. 


Q. Andy Taylor, Texas Instruments. About an hour or so ago a gentleman stood up here and 
talked about a problem he was having where he’s disk quota is becoming full. I would like 
to propose a variation on that theme. I have my allocated disk quotas going to 0. Also, 
on random IDs. 

A. What version of VMS have you witnessed this under? 

Q. What part, what version of VMS.... 

A. What version of VMS do we see the problem in? As far as I know we see this in 4.5 
onwards. 


Q. Pete ????, Dow Chemical, I’ll try to ask this question the previous, the hardware question 
and they said maybe it’s your guys problem. I’m interested in if there is anyway to take 
asynchronous DECnet, route it to a sync line, back out the sync line and go back in 
asynchronous. The reason this is important a lot of corporate networks have wonderful 
syncs line for the IBM boys and we’d like to hide asynchronous DECnet underneath it. 
We’ve tried some protocol converters to go async async and it always seems to royally 
screw up DECnet, anyway around it that anybody knows? 

A. We heard your question in the hard ware.... at least two consulted and we don’t know of 
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any way to do that. 

Q. I want to go async to sync, up back at another sync modem and go back into async. There 
are async to sync and sync to async converters, it’s just DECnet seems to get thoroughly 
mangled. You can use these things for example, asynchronous terminals work just fine 
through them, DECnet gets mangled though. 

A. Yeah, off hand I have no idea why. I mean, I’m sure what’s happening is something to do 
with the DDCMP protocol, but at this point I don’t really know and I could take it back 
and find out. 

A. No. What you’re really try to do is essentially run two data link protocols, one within 
the other and because of the nature of the DDCMP protocol it makes certain sets of 
assumptions that you’re going to violate. The same sort of problems have when you try 
to run async DECnet over broad band networks, over. 

Q. Excuse me we do run asynchronous DECnet over broad band quite successfully. Why 
would it care about the sync line though, I mean, it’s another ???? mux. It doesn’t care 
about the packets. 

A. When you’re going over the stat, if you’re going over any stat mux where async DECnet 
doesn’t own every bit of the band with the network you’re going to run into various 
problems. It will run sometimes for a few seconds, sometimes it won’t run at all. 

Q. Is that true if you even ran async through a stat mux, at synch. 

A. That would be depending on the nature of the stat mux, the same problem would occur. 

Q. Boy, we had that working successfully, okay. 


Q. Dell Merritt, The Analytic Sciences Corp. I have an 8200 running VMS 4.6, this is a back 
up and to you driver question because I also have it talking to TU81 plus. I noticed that 
my privileged users can use backup effectively all the time, non privileged users cannot. I 
called CSC to ask them about this, I was told that it was a 4.4 bug that was remedied in 
4.5 and slipped back in in 4.6 and they said please call back later a couple of weeks from 
now when we think we might have a patch and I haven’t had a chance to call them back. 
So, right now I’ve installed backup with ISO, I’ve also had to install in crypt share so it 
would work. Is there a patch out there now or what should I do? 

A. The history, the effects are right, the history is wrong. It wasn’t a problem that slipped 
in and slipped out again or slipped out and back in again. The problem was introduced 
in 4.6. As we speak the problem should have been solved. When I get back I’ll make sure 
that it’s distributed to CSC. You should be able to get the patch sometime next week or 
the week after I would imagine from CSC. I apologize for the inconvenience over it. 
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An Idle Process Killer, Chainsaw Massacre Style 

G. Beau Williamson, Rockwell International, Telecommunications Division, Richardson, TX 


Another chapter in the debate over 
the pros and cons of Capital Punishment 
for VAX computer processes 


A few years back, I took over the job of System Manager for a large VAX Cluster with 
over 600 user accounts. This particular VAXcluster is located in the building next to one of 
Rockwell’s major corporate IBM computing centers. Since this IBM facility is such a major 
Rockwell computing center, the Corporate Computer Auditors tend to make regular trips to this 
center to check up on things. 

We’re Computer Auditors And We’re Here To Help You 

As an indirect result of the close proximity of my VAX facility and the big IBM computer 
center, our corporate computer auditors seem to regularly “drop by” for a quick audit. (Since 
they just happened to be in the area checking on the big IBM center anyway.) 

I spent some time with these auditors and proudly explained all of the wonderful security 
features of VMS such as “Breakin Detection”, “Access Control Lists” and a few others. However, 
they were not to be impressed and politely pointed out that my VAX system was not up to 
snuff since VMS did not automatically logoff idle terminals as per Corporate Computing Policy 
umpty-ump dash something or other. They then proceeded to write up this audit item in their 
report and informed me that “You really must do something about this”. 

VAX SIG’s “Wheel of Autologout Programs” Game 

I decided that all of this was really no big deal as I had seen some submissions on the VAX 
SIG tape for autologout programs. In fact, when I scanned the tapes, I found so many autologout 
programs on the SIG Tapes that I couldn’t make up my mind which one to use. Finally, I just 
sort of closed my eyes and figuratively spun the VAX SIG “Wheel of Autologout Programs” and 
picked one. Unfortunately, VMS V4.0 had just been put on our Cluster and all of the autologout 
programs had been written for V3.7 of VMS. This meant I was going to have to do some rewriting 
to make things work correctly. 

What’s In A Name 

Keep in mind that I was short on time so I had to carefully allocate the little time available 
to the more important aspects of writing this program. Therefore, I spent about 80% of the 
available time on the number one priority — coming up with a name for the program. 

You’ve got to understand that I didn’t want some wimpy sounding name for this program. 
I believe that it is important that computer users maintain a certain amount of fear and respect 
for their Computer System (and System Manager). Just think, how would you respond if you 
received a message on your terminal that looked something like this: 

y,FR00FIE-W-IDLE, You are about to be logged out by ‘‘Froofie The Watchdog’ ’ ! 
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Doesn’t exactly strike fear and terror into a user’s heart, does it? No, I didn’t think so. 
The problem was to find a really good name that, when mentioned in casual conversation to a 
user, would trigger a conditioned reflex manifesting itself in an overpowering urge to run madly 
about the room searching for a VT220 on which to type the word “LOGOUT”! This is referred to 
by Computer Psychologist as the “Pavlovian Method” of terminal security. 

Several names were tried initially but none seem to be quite the ticket. I quickly came up 
with the name “PR0CESS_P0LICE” and just as quickly dismissed it as too trite. I kind of liked 
the name “DETACHED_DEATH” but discarded it as a bit too heavy handed. I had recently seen the 
movie “Friday the Thirteenth” and began to think that if I bought a Hockey Mask and wore it 
to work for about two weeks and then simply named the program “JASON”, I could just about 
achieve the desired result. This idea was also discarded as I didn’t have the two weeks necessary 
to establish the behavior modification of the users that I desired by wearing the Hockey Mask to 
work. 


I finally decided that the name “SECURITY” had a nice official ring to it with enough hint 
of authority to keep the users in line. Since by now I was nearly out of time, I spent the remaining 
20% of the time rapidly coding the changes to about 45% of the original program. After a couple 
of quick checks, I put “SECURITY” online and went on to other more interesting System Manager 
tasks such as fiddling with SYSGEN parameters that I knew nothing about in order to see what 
affect they had on the system. 

For a while, life at my VAX facility was uneventful. I had, via trial-and-error, identified 
some of those pesky SYSGEN parameters that shouldn’t be fiddled with (I don’t recommend setting 
QUANTUM down to 2!) and SECURITY seemed to be working quite fine. Oh, I did have to explain 
to those users that liked to login early in the morning and just leave their terminal logged in, that 
they could no longer do that. Other than that, life as System Manager was uneventful. That is 
until the day SECURITY flipped out! 

Security Goes Schizophrenic 

It happened at mid-morning when the computers are at their peak usage in terms of the 
number of users logged on. I was working in my office at the time when there arose a great hue 
and cry from the applications programmers in the open bay area just outside my office door. I 
heard someone yelling, “ Security is logging everyone off! Security is logging everyone off!” This 
was followed by the appearance of a wide-eyed application programmer at my door who looked 
as if he had just seen a ghost. “Did you know that Security is logging everyone off?”, he inquired 
in such a way that I thought if I were to reply “Yes, I know”, he would have just responded “Oh, 
Ok” and returned to his desk. However, I could tell from the other frenzied yells coming from 
over his shoulder that this was one problem that I had better not put off until tomorrow. 

I went to the first terminal in the bay area that was being used by one of the applications 
programmers. Sure enough, a series of messages from Security of the form 


SECURITY - 

You 

will 

be 

logged 

out 

in 

20 

mins. 

Idle 

for 

10 

mins. 

SECURITY - 

You 

will 

be 

logged 

out 

in 

15 

mins ♦ 

Idle 

for 

15 

mins. 

SECURITY — 

You 

will 

be 

logged 

out 

in 

10 

mins. 

Idle 

for 

20 

mins. 


were appearing in rapid, count-down succession on the programmer’s terminal at an in¬ 
terval of about 2 seconds. Not only that, no amount of typing seemed to deter Security from its 
inevitable outcome of killing the programmer’s process. In the end, in less time that it has taken 
you to read this paragraph, Security killed the programmer’s process and logged him off. All of 
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this time, I had a vivid mental image of some of our less knowledgeable users, who thinking that 
they were not working fast enough to keep the computer happy, were madly typing as fast as they 
could in a forlorn attempt at staving off Security; all to no avail. Not only had Security killed the 
programmer’s process, it was now apparent that it was on a frenzied “killing” spree from which 
it seemed, no interactive process could escape. 

I logged in as fast as I could as SYSTEM in an attempt to stop this mass murder! Unfortu¬ 
nately, I was too late. By the time I could get logged in, Security had completed its grizzly job 
and had left no interactive process alive. A quick SHOW SYSTEM confirmed this fact but it also 
showed something else very strange, Security was no where to be seen ! 

After some investigating as to what happened to Security, I came up empty handed. No 
one had any privileges to stop Security but myself and the day operator. He said he too was 
unable to get logged on before Security had finished hosing down the system. This left me with 
only one possible solution as to where Security went after committing mass processcide. 

AAI - Accidental Artificial Intelligence 

Evidently, I had accidentally embedded some small kernel of Artificial Intelligence in Se¬ 
curity when I made all of those changes. (Which is a pretty good trick considering I never got 
around to taking LISP programming in College.) I figured that this AI kernel must have grown 
into some small degree of a “sense of right and wrong” because after going on its shooting spree, 
Security must have realized that it had done something “very wrong” and being overcome with 
guilt, turned the gun on itself! 

Then I began to think that it was possible that it wasn’t a sense of “right and wrong” at 
all that caused Security to kill itself. I may have given myself too much credit for accidentally 
giving my program a sense of morality. It was just possible that my program was a heartless 
killer with no feelings for its fellow process. I must admit to some degree of responsibility for 
Security’s actions as its foster parent (remember I re-wrote about 45% of the code). You know 
you do your best to bring programs up right in today’s VAX architecture. But, sooner or later 
you have to “detach” them and when you do there are no guarantees that they won’t someday 
break your heart. 

Finally, I had to face the fact that my Security program might not have had any feelings 
of remorse what-so-ever and simply realized that it was surrounded and didn’t have a chance to 
escape. Maybe it had vowed never to be taken “alive” and to subsequently be sentenced to Life 
in “Process Prison”. (This consists of being Swapped-out to a tiny Swap File on an unused disk; 
after which, the disk’s Unit Plug is pulled and thrown away.) In any case, we will never know 
what last thoughts went through Security’s PO space on that fateful day. 

Post Mortem Of A Privileged Process 

After the excitement died down over all the users getting logged out by Security, I begin 
the process of a post mortem on Security. Since I was unable to get logged on in time to do 
anything while Security was running and since the exit status in the accounting file didn’t show 
anything to indicate what the root of Security’s antisocial behavior was, I had to resort to the age 
old method of program debugging — read the program listings and “out think” the computer. 

I began to go over the listings very carefully and everything seemed to be in order. 
“Hmmm”, I thought to myself as I scanned the listings, “here’s where SYS$GETJBI is called 
over and over to get data on processes; here’s were processes that have been idle are detected 
and here’s where idle processes are warned via a message output by a call to SYS$QI0W.” “Yep, 
everything sure looks OK, so what the heck is Then it hit me, “What a minute, QIO and 
WAIT, could that be it?” Slowly the problem began to take shape and I formulated a scenario 
that after some further research I felt to be the cause of the problem. 


VAX-29 



A Scenario for Disaster 


Here’s what happened. Security had run just fine for several days until some user had 
typed the <Hold-Screen> key and then walked away from the terminal. After the appropriate 
amount of delay, Security attempted to issue the first warning message to this now idle process. 
Unfortunately, the I/O was unable to complete since the <Hold-Screen> was still in effect. Now 
Security was hung until someone type the <Hold-Screen> key on that terminal again. This 
wouldn’t have been a catastrophic error had Security’s rescheduling algorithm been correct (a 
section of the code I hadn’t bothered to modify, I might add in my own defense). It turns out 
that the original program used an absolute time computation to schedule the next wakeup time 
for the program by simply adding a fixed time interval to the last scheduled wakeup time. 

Now I could postulate the scenario that led up to the disaster. Like I said, it all started 
when a user typed the <Hold-Screen> key and then went to get coffee. Security soon attempted 
to warn the terminal and then hung in the SYS$QI0W. About an hour later, the user returned 
from the extended coffee break and typed the <Hold-Screen> key again in order to start a short 
“work-break”. Security then completed the I/O to the terminal and rescheduled itself to run 
again at an absolute time that had come and gone nearly an hour ago! The result was that 
Security went into hibernation and immediately woke up again. Thinking that some reasonable 
interval had passed (we use 5 minute intervals), Security looked around and saw that virtually 
all interactive processes had been idle during the last time interval and proceeded to warn every 
process on the system. 

Once again Security computed the absolute time of the next wakeup (which was still nearly 
an hour in the past) and put itself into hibernation once more only to be awakened immediately. 
This repeated itself on and on until the final climax resulting in Security coming to the erroneous 
conclusion that everybody had been idle for the prescribed time period and should therefore be 
killed. 

Epilogue 

A new version of Security is now running on my system. I changed the SYS$QI0W to a non¬ 
waiting form of SYS$BRKTHRU in order to “write through” anything pending on the user’s terminal 
and to not wait around for the I/O to complete. I also changed the rescheduling algorithm to 
compute the next wakeup interval using delta times. 

Security has now become the respected idle terminal policeman that I originally had in 
mind. The users have become used to his warning messages and actually logoff when they are 
not using the terminal. The new version has been stable for so long that I no longer worry about 
Security becoming deranged and causing the process carnage that his predecessor did. In fact, I 
now have the time to get back to fiddling with a couple of other SYSGEN parameters that I never 
had time to mess with before. Hmmm, I wonder what happens when you set LGI_PWD_TMO down 
to 1 second. 
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DECUS PROGRAM LIBRARY 


Corrections to programs that have been announced 
through this report 

DECUS No. VAX-328, Title: SCOPY: 

. WITHDRAWN VAX-328 has been withdrawn from 
the Library as requested by the 
author. DECUS No. VAX-329, Title: 
SVIEW/SCOPY replaces VAX-328. 

VAX-329 is announced as being 
available in this report. 

NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

VAX/VMS FAMILY OF COMPUTERS 

DECUS No: VAX-318 Title: Micro-FLX Version: 1.2, 
February 1988 

Submitted by: Trevor Taylor, Microcomputer Technol¬ 
ogy ,Chatswood, NSW, Australia 2067 

Operating System: Micro VMS V4.4 - 4.6, VAX/VMS V4.6 
Source Language: C, VAX FORTRAN Hardware Re¬ 
quired: RX33 or RX50 Floppy Diskette Drive Keywords: 
Data Communications, Utilities - VMS 

Abstract Micro-FLX is a file transfer program designed 
to allow VAX users to read and write CP/M and MS/DOS 
floppies. It handles RX50 diskettes in either CP/M or 
MS/DOS format from a Rainbow or RX33 diskettes in 
MS/DOS format from a VAXmate. Floppies can be 
mounted in an appropriate disk drive on either a VAX or 
a MicroVAX, and files can then be copied to and from 
them using commands similar to DCL. There is also 
built In help. 

Release notes are distributed with each order. 

Sources not included. 

Media (Service Charge Code): One RX50 Diskette (JA) 
Format VMS/BACKUP, 600’ Magnetic Tape(MA) For¬ 
mat VMS/BACKUP 

DECUS No: VAX-329 Title: SVIEW/SCOPY Version: 
1.0, March 1988 

Submitted by: John T . Carroll III, Columbus, IN 

Operating System: MicroVMS V4.6 Source Language: 
VAX FORTRAN Hardware Required: VT200, VT300 
Terminals Keywords: FORTRAN, Graphics, ReGIS 

Abstract SVIEW is a FORTRAN program that displays 
screen images saved by the SCOPY subroutine on Digital 
Equipment Corporation’s VT200 and VT300 series gra¬ 
phics terminals. Once invoked, SVIEW prompts the user 
for commands to READ a plot file, VIEW a screen image, 
PLOT a screen image, and EXIT the program. 


SCOPY is a FORTRAN subroutine that transfers images 
displayed on Digital Equipment Corporations’s VT200 
and VT300 series graphics terminals to a plot file. The 
transfer is accomplished by initiating a remote screen 
copy and redirecting the screen image from the printer 
port to the host. The resulting plot file can be printed on 
any one of Digital Equipment Corporation’s graphics 
printers or rapidly redisplayed at the terminal using the 
SVIEW program. 

Media (Service Charge Code): One RX50Diskette(JA) 
Format: VAX/ANSI, 600’ MagneticTape(MA) Format 
VAX/ANSI 


DECUS No: VAX-330 Title: VTCALC Version: 1.0, 
April 1988 

Submitted by: Michael Chamsay 

Operating System: VAX/VMS Source Language: VAX 
BASIC Hardware Required: VT100 or VT220 Terminal 
Keywords: Calculators 

Abstract VTCALC is an easy to use, simple calculator 
program that does basic calculations. All input is done 
via the keypad and arrow keys which are diagrammed on 
the screen using the line drawing character set. Like 
many simple calculators it has one memory cell which is 
displayed on the screen and updated whenever the store 
key is pressed. This program was developed and tested 
on a VT220 look alike in VT100 mode. One of the future 
enhance-ments will be to include scientific functions such 
as trigonometic, and log functions. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format VAX/ANSI 


DECUS No: VAX -332 Title: Menu Branch Version: 1.1, 
April 1988 

Submitted by: Bob Bruhin, Advanta, Building Five, 
Horsham, PA 

Operating System: VAX/VMS V4.7 Source Language: 
MACRO-32 Memory Required: 25.6KB Keywords: 
Menu Control, Tools - Applications Development 

Abstract This tool takes the form of a MACRO-32 pro¬ 
gram which can replace the display and selection por¬ 
tions of a captive menu command procedure. Using this 
tool, captive menus are still DCL command procedures 
(like at most installations). However, the burden of cod¬ 
ing the routines to display the menu, accept a user selec¬ 
tion and execute the appropriate DCL code to perform 
the selected action is removed from the designer of the 
menu. The menu program can perform all these actions 
from within the command procedure. 

The menu program may be considered a multi-way DCL 


branch statement The command procedure calls the 
menu program using the DCL RUN command. A menu 
description is included in-line in the command pro¬ 
cedure, following the activation of the menu program. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format VMS/BACKUP 

DECUS No: VAX-333 Title: VT100KEYS Version: 1, 
March 1988 

Submitted by: Ronald William Burke, Westinghouse 
Electric Corporation, Baltimore, MD 

Operating System: Micro/VMS V4.X, VAX/VMS V4.X 
Source Language: DCL, VAX FORTRAN Keywords: 
Terminal Handler 

Abstract VT100KEYS shows users how to use the key¬ 
pad on a VT100 terminal. It allows you to lock or unlock 
terminal or console from unauthorized access. It includes 
a pair of DCL commands (LOCK.COM and CLOCK- 
.COM) which approximate VTlOOKEY’s locking cap¬ 
abilities on terminals and consoles. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format VMS/BACKUP 


DECUS No: VAX-334 Title: LASER_FORMAT Ver¬ 

sion: 2, April 1988 

Submitted by: Dr. David W. Burgess, RAF Institute Of 
Aviation Medicine, Famborough, Hants, England, GN14 
6SZ 

Operating System: MicroVMS V4.7, VAX/VMS V4.6 
Source Language: VAX FORTRAN Hardware Required: 
Postscript Laser Printer Keywords: Text Formatting 

Abstract LASER-FORMAT is a file interpreter to mod¬ 
ify either Bonner RUNOFF, WPS, or Normal text lis¬ 
tings for output on a PostScript Laser printer. Command 
files exits to catch files for listing from a directory [ LASER] 
for automatic printing on a laser print queue. Using 
escape codes additional postscript commands can be 
added to the files to produce pretty output of desk top 
publishing quality. Codes exist for full support of the 
technical character set in WPS. Wordstar files can also 
be printed on this package over DECneL 

The package contains three demonstration manuals for 
output either as a straight text file, a RUNOFF file or via 
WPS-PLUS if this program is available. 

Package also contains an updated version of DECUS 
Program No. VAX-212, “PLOT_IT and SPELL: Inter¬ 
active Dicionary”, a Graph plotting program. 

Media (Service Charge Code): Five RX50 Diskettes 
(JE) Format VMS/BACKUP, 600’ Magnetic Tape (MA) 
Format VMS/BACKUP 


DECUS No: VAX-335 Title: DBAG- Data Base System 
Version: 1.0, January 1988 

Submitted by: Luis Arriaga Da Cunita, Laboratorio 
Nacional De Engenharia Civil, 1799 Lisboa Codex, Por¬ 
tugal 

Operating System: VAX/VMS V3.4 - V4.6 Source Lan¬ 
guage: VAX FORTRAN Memory Required: 1MB Key¬ 
words: Data Base Management 

Abstract DBAG is a relational database system, im¬ 
plemented for VAX/VMS, similar in functionality and 
interactive interface, to the commercial product DBASE 
III. Some commands are actually the same, so users 
familiar with that popular package should “feel at home’’ 
with little effort 

The editor of records (and commands) departs fipm a 
WordStar-like approach and emulates VAX’s EDT thus 
again saving extra learning effort 

The system also provides a complete library of, sub¬ 
routines, FORTRAN 77 callable, for those who heed/ 
want to write their own program to handle the database 

Media (Service Charge Code): 2400’ Magnetic Tape 
(PA) Format VMS/BACKUP 

DECUS No: VAX-336 Title: FTX Version: 4.5, April 
1988 

Submitted by: C.J. Chapman, Philips Defence Systems 
MEL, Crawley, Sussex, England, RH10 2PZ 

Operating System: MicroVMS V4.7, VAX/VMS V4.5 
Source Language: MACRO-32 Memory Required: 60KB 
Virtual Allocation Keywords: System Management - 
VMS, Utilities - VMS 

Abstract FTX - Foreign Tape Extension utility is a sys¬ 
tems management tool that enables ASCII or EBCDIC 
data files to be written, or read from magnetic tape using 
any combination of block and record format. The utility 
uses VMS command definition language. 

Features include: 

. Automatic tape mount and dismount with no unload. 

. Forward tape mark skipping before read begins. 

. Full wild card file processing. 

. Record padding and stripping. 

. Read while spooling option. 

. Data I/O CHECKING.* 

Release notes are distributed with each order. 

Notes: Operating System VMS V4.0 or later is required. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format: VMS/BACKUP 
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NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

PDP-11 COMPUTER FAMILY 

DECUS No: 11-901 Title: TIDY DIRECTORY PRO¬ 
GRAM Version: January 1988 

Submitted by: Sanjay Dasgupta, Gas Authority of India 
Ltd, New Delhi, India, 110021 

Operating System: RSX-11M-PLUS V2.1 Source Lan¬ 
guage: FORTRAN 77, MACRO-11 Memory Required: 
40KB Software Required: Device independent cursor 
positioning option of full duplex terminal driver(RSX 
Sysgen option). Hardware Required: VT100 Compatible 
Terminal Keywords: Utilities - RSX-11 

Abstract: The TIDY DIRECTORY PROGRAM (TDP) is 
a screen-based utility that helps you to keep your direc¬ 
tory tidy. TDP shows you summary information about 
your files, calling attention to those that exist in multiple 
versions, and provides single-key-stroke purging and 
deleting capability. You can also examine the contents of 
any file before deciding to purge or delete it. All these 
functions are available from within TDP, and you never 
have to use PIP, TYPE, DELETE, PURGE, or PRINT. 

TDP presents summaries grouped by file type, so you are 
always aware of the file groups in your directory. At the 
author’s installation every user who uses TDP has in¬ 
variably found (and deleted), groups of files whose exis¬ 
tence they would not have otherwise known. This is 
particularly true of active users who always examine 
directories by selective wildcarding. 

Because TDP exploits VT100 video features and the 
applications key-pad, the file directory is never more 
than a few key strokes away from a file-contents display, 
and PURGING and DELETING tools. This makes it a 
particularly effective and fast way of hacking away the 
dead wood from your directory. 

Restrictions: The RSX operating system must be sys- 
gened with the device independent cursor positioning 
option. 

Documentation available in hardcopy only. Complete 
sources not included. 

Media (Service Charge Code): User’s Manual (EA), 
One RX01 Diskette (KA) Format FILES-11, 600’ Mag¬ 
netic Tape (MA) Format FILES-11 


Operating System: MicroVMS V4.7, VAX/VMS V4.6 
Source Language: MACRO-32 Memory Required: 13.8KB 
Virtual Allocation Keywords: System Management - 
VMS 


Abstract The VIEW utility is a system management tool 
that enables the Systems Manager to obtain information 
on system processes or user processes. VIEW is very use¬ 
ful for taking a snapshot look at your system to establish 
what images are currently executing. VIEW executes on 
Digital Equipment Corporation VT200 Series terminals 
continuously displaying the following information: 

User Name or Process Name, Image Name, Process 
Id. 

. Login Time, Uic, Process State/Type, CPU Min/Sec. 

. Base Priority, Current Priority, Working Set Size. 

. Image Activation Count, Disk I/O, Buffered I/O. 

. Page Faults, VMS Release, Balance Set, Node Name 
. Idle Time and Uptime since boot time, Date Time 
. Process alternate, device directory and terminal. 

VT220 Terminal Keypad Functions: 


Process User or Process Name 
Increase Interval Time 
. Decrease Interval Time 
. Increase Page Number 
. Decrease Page Number 
Clear Page 

Enable/Disable Highlight 
Process Alternate 
. Highlight Process 
Delete Process 
Increase Base Priority 
Decrease Base Priority 
To Exit type Ctrl__y, Ctrl_c 


(Select) 

(Up_Arrow) 

(Down_Arrow) 

(Next_Screen) 

(Previous_Screen) 

(Do) 

(Find) 

(Select) 

(Up/Down_Arrow) 

(Remove) 

(Rights Arrow) 

(Left_Arrow) 

or (F6). 


To continuously VIEW Balance set, Idleup, and Date 
Time, use the following procedure: 


. Decrease Interval Time to zero. 
. Clear Page using the (Do) key. 


Release Notes are distributed with each order. 


Notes: Operating system VAX/VMS V4 or later is re¬ 
quired. 

Changes and Improvements: Minor code changes. 

Media (Service Charge Code): 600’ Magnetic Tape (MA) 
Format VMS/BACKUP, or order VAX-LIB-8 


REVISIONS TO LIBRARY PROGRAMS 

DECUS No: VAX-286 Title: VIEW Version: 5.1, March 
1988 

Submitted by: C.J. Chapman, Philips Defence Systems 
MEL, Crawley, Sussex, England, RH10 2PZ 


DECUS No: 11-462 Title: TERM.FOR Version: 5.1, 
April 1988 

Submitted by: Richard Desper, U.S. Army Materials 
Technology Lab., Watertown, MA 

Operating System: RT-11 V5.0 Source Language: FOR¬ 
TRAN IV Memory Required: 56KB Software Required: 
RT-11 Sysgened for Multi-terminal support Hardware 


Required: DLV-11J Quad Serial Interface Keywords: 
Data Communications, Emulators 

Abstract TERM is written in FORTRAN to convert a 
PDP-11/23 with a DLV-11J Quad Serial Interface into a 
smart terminal. The program allows the PDP-11/23 con¬ 
sole terminal to converse with a remote computer. Disk 
files on the PDP-11/23 may be accessed as either sources 
or sinks for ASCII data files. File transfer is limited to 
ASCII files and is not automatically checked for errors, 
but is quite reliable at speeds up to 2400 baud. (A second 
speed limitation is that the remote computer baud rate 
must be slower than the PDP-11/23 console terminal 
rate, 9600 baud at this installation .)TERM is sufficiently 
transparent to the user to allow editingoperations on the 
remote computer, ag. VAX/VMS EDT using VT100 or 
VT200 terminal support For possible use with a remote 
VAX, aVMSfileTERM.COM is also provided to facilitate 
file transfer. Further details are in the file TERM.DOC 
and as comments in TERM.FOR 

Notes: Operating system RT-11 V5.0 or higher is re¬ 
quired. 

Changes and Improvements: Control Z from either the 
terminal or the remote host stops all file transfer. 

Restrictions: Console terminal baud rate must be faster 
than 

“Modem” (connected to remote host) baud rata 

Media (Service Charge Code): OneRXOl Diskette(KA) 
Format RT-11, 600’ Magnetic Tape (MA) Format RT- 
11 


LIB-3 


LIB-4 



STEERING COMMITTEE LISTS 



ARTIFICIAL INTELLIGENCE SIG 

CHAIR 

Cheryl Jalbert 
JCC 

128 West Broadway 
Granville, OH 43023 

(614) 587-0157 

VICE-CHAIR 

OPS5 WORKING GROUP CHAIR 

Don Rosenthal 
Space Telescope Science Inst. 
Homewood Campus 
Baltimore, MD 21218 
(301) 338-4844 

NEWSLETTER TASK FORCE CHAIR 
ADMINISTRATIVE ASSISTANCE 

Becky Wise 
Amdalh CSD 

2200 North Greenville Ave. 

Richardson, TX 75081 
(214) 699-9500 x 272 
NEWSLETTER EDITOR 
Terry Shannon 
Computer Info. Sys., Inc. 

Technical Consultant 
165 Bay State Drive 
Braintree, MA 02184 
(617) 848-7515 

SYMPOSIA COORDINATOR 

Pam Vavra 

Hughes Aircraft EDSG 
P.O. Box 902 E52/D220 
El Segundo, CA 90245-0902 
(213) 616-7071 

MEMBERSHIP COORDINATOR 
SUITE COORDINATOR 

Chris Goddard 
Simpact Associates 
9210 Skypark Court 
San Diego, CA 92123 
(619) 565-1865 

SESSION NOTE EDITOR 

George Humfeld 
Naval Sea Systems Command 
PMS 350 ED Dept of the Navy 
Washington, DC 20362-5101 
(202) 692-0137 

ASS’T SESSION NOTES EDITOR 
David Frydenlund 
STORE REPRESENTATIVE 

Sally Townsend 
Inst. Defense Analysis 
1801 N. Beauregard St. 

Alexandria, VA 22311 
(703) 845-2122 

PUBLIC DOMAIN SOFTWARE TF CHAIR 
LIBRARY REPRESENTATIVE 

Jim Sims 

Space Telescope Science Ins. 

3700 San Martin Drive 
Baltimore, MD 21218 
(301) 338-4949 

AI LUG COORDINATOR 
ASSISTANT STORE REP. 

Dennis Clark 
RT2 Box 264 
Kingston, TN 37763 

(615) 576-7384 

REPORTER TO THE UPDATE,DAILY 

Bill Lennon 


SEMINAR UNIT REP. 
CAMPGROUND COORDINATOR 
Leona Fluck 

Educational Testing Service 
Rosedale Road 
Princeton, NJ 08540 
(609) 734-1243 
DEC COUNTERPART 
Art Beane 
Hudson, MA 

MEMBERS-AT-LARGE 

David Slater 
George Winkler 
Jeff Fox 

John Williamson 

Wayne Graves 

Matt Mathews 

Dave Campbell 

Shirley Boekstahler-Brandt 

Barry Breen 

Tom Viana 



BUSINESS APPLICATIONS SIG 

CHAIRMAN 

George Dyer 
Gallaudet University 
800 Florida Ave, NE-EMG Bldg 
Washington, DC 20002 
(202) 651-5300 

COMMUNICATIONS COORDINATOR 

Steve Lacativa 
Price Waterhouse 
153 East 53rd Street 
New York, NY 10022 
(212) 371-2000 x 3107 
SYMPOSIA COORDINATOR 
Mark Hults 

USSA Administrative Systems 
USSA Bldg. B01E 
San Antonio, TX 78288 
(512) 498-8725 
LUG COORDINATOR 
Patrick LeSesne 
U.S. Coast Guard 
Room 1416E 2100 2nd SL SW 
Washington, DC 20593 
(202) 267-0354 

MARKETING COORDINATOR 

Tom Byrne 
L. Karp & Sons 
1301 Estes 

Elk Grove Village, IL 60007 
(312) 593-5706 

PROGRAM PLANNING COORDINATOR 

Stuart Lewis 
Douglas Furniture Corp. 

P.O. Box 97 

Bedford Park, IL 60499 
(312) 458-1505 

SEMINARS COORDINATOR 

Daniel Esbensen 
Touch Technologies, Inc. 

9990 Mesa Rm , Rd. #220 
San Diego, CA 92121 
(619) 455-7404 
LRP COORDINATOR 

Arnold I. Epstein 
D-M Computer Consultants 
Rolling Meadows, IL 60008 
(312) 394-8889 


NEWSLETTER EDITOR 

Dave Levenberg 
Credit Suisse 
Dept OAl 15th floor 
100 Wall Street 
New York, NY 10005 
(212) 612-8372 

SESSION NOTE EDITOR 

Marty Schmitt 
Harris Publishing 
3 Barker Avenue 
White Plains, NY 10601 
(914) 946-7500 x 287 
LIBRARY REPRESENTATIVE 
David Hittner 
Projects Unlimited 
3680 Wyse Road 
Dayton, OH 45414 
(513) 890-1800 
CL SIG LIAISON 

Becky Burkes-Ham 

DMS SIG LIAISON Joe Sciuto MEMBERS-AT-LARGE 

Robert D. Lazenby 
Dixie Beer Dist., Inc. 

Louisville. KY 
Robert Kayne 
Gallaudet College 
Washington, DC 
Ray Evanson 
Paragon Data Systems 
Winona, MN 

DEC COUNTERPARTS 

Sue Yarger 

Digital Equipment Corporation 
Merrimack, NH 03054-0430 
Paula Daley 

Digital Equipment Corporation 
Merrimack. NH 03054-0430 
Pam Kukla 

Digital Equipment Corporation 
Maynard, MA 01754 
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DATATRIEVE/4GL SIG 

CHAIRMAN 

Donald E. Stern Jr. 

Warner Lambert Company 
10 Webster Road 
Milford. (T 06460 
(203) 783-0238 

SYMPOSIA COORDINATOR 

Lisa M. Pratt 
Vitro ('orporation 
Nuwes (’ode 3144 
Keyport. WA 98345 
(206) 396-2501 

ASST SYMPOSIA REPRESENTATIVES 

T.C. Wool 

E.I. duPont I)eNemours& Co. 
Engineering Dept. 

P.O. BOX 6090. 

Newark. I)E 19714-6090 
(302) 366-4610 
Janet G. Banks 
Weyerhaeuser Info. Sys. 

Mail Stop CCB-2E 
Tacoma, WA 98477 
(206) 924-4082 
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COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Joe H. Gallagher 
Research Medical Center 
2316 East Meyer Blvd. 

Kansas City, MO 64132 
(816) 276-4235 

COMMUNICATION REPRESENTATIVE 
PRODUCTION EDITOR 

Steve Cordiviola 
Kentucky Geological Survey 
311 Breckinridge Hall 
Lexington ,KY 40506 

(606) 257-5863 

ASSOCIATE NEWSLETTER EDITOR 

Pasquale (Pat) F. Scopelliti 
Corning Glass Works 
Mail Stop MP-RO-Ol-1 
Corning, New York 14831 

(607) 974-4496 
Lorey B. Kimmel 
Digital Equipment Corp. 

6707 Whitestone Road 
Baltimore. MD 21207 
(301) 298-1500 
Herbert G. Reines 

Reznick Feddder & Silverman 
4520 East West Highway 
Suite 300 

Bethesda, MI) 20814 
(301) 652-9100 
Alan Winston 

Stanford Synchrotron Radiation Lab. 
SLAL BIN 69 
PD .Box 4349 
Stanford. CA 94305 
(415) 854-3300 x2874 
VOLUNTEER COORDINATOR 
Susan Krentz 
NKF Engineering 
12200 Sunrise Valey Dr. 

Reston. VA 22091 
(703) 620-0900 

ASSISTANT VOLUNTEER COORD. 

Harry Miller 
City of Ontario Police 
200 N. Cherry Avenue 
Ontario, CA 91764 
(714) 988-6481 

SEMINARS COMMITTEE REP. 

Dana Schwartz 
15719Millbrook Lane 
Laurel. MD 20707 
(301) 859-6277 

SESSION NOTES EDITOR 

Bernadette Reynolds 
City of Ontario Police 
200 N. Cherry Avenue 
Ontario, CA 91764 
(714) 988-6481 
SUITE COORDINATOR 
Bert Roseberry 
Commandant (G-APA-1) 

2100 2nd Street.S.W. 

Washington. DC 20593-0001 
(202) 267-2629 
FEATURE EDITOR 

Philip A. Naecker 
Consulting Engineer 
3011 N. Mount Curve Ave. 

Altadena, CA 91001 
(818) 791-0945 
DEC COUNTERPARTS 

Mary Ann Fitzhugh 
110 Spit Brook Road 
ZK2-2/M 28 
Nashua. NH 03060 
(603) 881-2329 

ARTIST & LIBRARY REP. 

Bart Z. Lederman 
WU World Communications 
67 Broad Street (28th Floor) 

New York. NY 10004 
(212) 607-2657 


RALLY WORKING GROUP CHAIR 

Steven G. Fredrickson 
Fredrickson Consulting Service 
107 1st Avenue N. 

Seattle. WA 98109 
(206)283-0273 

POWERHOUSE W/G CHAIR 

David Nagumey 
TSO Financial Corp. 

Five TSO Financial Center 
Three Hundred Welsh Road 
Horsham, PA 19044-2009 
(215) 657-4000 
DMS SIG LIAISON 
William Tabor 
W.I.Tabor, Inc. 

12018 Royal Palm Blvd. 

Coral Springs. FL 33065 
(305) 755-7895 

SMARTSTAR WORKING GROUP CHAIR 

Thomas Colati 
Time Enterprises 
301 North Harrison 
Suite 101 

Princeton. NJ 08540 
(800) 548-6865 

ACCENT R USER GROUP LIAISON 

Winston Tellis 
Fairfield University 
North Benson Road 
Fairfield. CT 06430 
(203) 255-5411 

FOCUS WORKING GROUP CHAIR 

Les Hulse 

The Gillette Company 
Prudential Tower Bldg. 

Boston. MA 02199 
(617)421-7910 



DAARC SIG 

CHAIRMAN 

James Deck 

Inland Steel Research Lab. 
3001 East Columbus Drive 
East Chicago, IL 46312 
(219) 392-5613 

SYMPOSIA COORDINATOR 

Mack Overton 
FDA 

Chicago, IL 


COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Dale Hutchison 
Cummins Engine Co. 

4720 Baker St, Ext 
Lakewood, NY 14750 
(716) 456-2191 
DEC COUNTERPART 
Bill Forbes 
Marlboro, MA 


HARDWARE & INTERFACING 

Peter Clout 

Los Alamos National Lab 
Los Alamos, NM 

MATH STATISTICS & ANALYSIS 
Herbert J. Gould 
C.C.F.A. Univ. of Ill. Medical Ctr. 

Chicago, IL 

PROCESS CONTROL-INDUSTRIAL AUTOMATION 

Bill Tippie 

Kinetic Systems Corp. 

Lockport IL 

RS-1 

George Winkler 
CPC International 
Argo, IL 



DATA MANAGEMENT SYSTEMS SIG 

CHAIRMAN 

Doug Dickey 

GTE Government Systems 
1700 Research Blvd. 

Rockville, MD 20850 
(301) 294-8462 
MEMBER AT LARGE 
Alan Schultz 

Southwestern Bell Yellow Pages 
12800 Publication Dr., Suite 108 
St. Louis, MO 63131 
(314) 957-2029 

SYMPOSIA COORDINATOR 
SQL Standards Rep. 

Keith Hare 
JCC 

P.O. Box 463 
Granville, OH 43023 
(614) 587-0157 

COMMUNICATIONS REP. 

Debbie Kennedy Coleman 
Shane Co. 

2 W Washington St., Suite 600 
Indianapolis, IN 46204 
(317) 635-9100 
NEWSLETTER EDITOR 
William Packard 
Mass Mutual Life Ins. 

1296 State Street B-391 
Springfield, MA )1 111 
(413) 788-8411 

SESSION NOTE EDITOR 
Mark Morgan 
Farm Credit Banks 
P.O. Box 141 
Springfield, MA 01102 
(413) 786-7600 

MEMBERSHIP COORDINATOR 
MEMBER AT LARGE 
Rocky Hayden 
Userware International 
2235 Meyer Avenue 
Escondido, CA 
(619) 745-6006 
MEMBER AT LARGE 
PAST SIG CHAIRMAN 
Steve Pacheco 
Ship Analytics 
North Stonington, CT 06359 
(203) 535-3092 
PAST SIG CHAIR 
MEMBER AT LARGE 
Joe Sciuto 
U.S. Army 

5910 Westchester Street 
Alexandria, VA 22310 
(202) 692-6903 
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SEMINAR REP. 

Stephen Gomez 
Signal Technology 
1700 Montgomery St. 

San Francisco, CA 94111 
(415) 954-8582 

WORKING GROUP COORDINATOR/ 

Jim Perkins 
PSC, Inc. 

20 Kimball Ave., Suite 305 
Shelburne, VT 05401 
(802) 863-8825 

CAMPGROUND COORDINATOR 

Rosemary O’Mahony 
Arthur Anderson & co. 

33 West Monroe Street 
Chicago. IL 60603 
(312) 507-6510 

SESSION CHAIR COORDINATOR 

Andy Menezes 
AD & E 

29-B Montvale Avenue 
Woburn. MA 01801 
(617) 938-1979 

Rdb WORKING GROUP Coordinator 

Howard Cheng 

Bechtel Western Power Corp. 

12440 East Imperial Highway 
Norwalk. ('A 90650 
(213) 807-4077 

ROADMAP COORDINATOR 

Elizabeth Irving 

Dupont 

P.O. Box 1089 

Orange, Texas 77630-1089 

(409) 886-9427 

DBMS COORDINATORS 

Bryan Holland 
1006 Pleasant St. #20 
Weymouth, MA 02189 
(617) 335-7573 
Paul E. Reese 
Aetna, Systems Dept 
Financial Division 
City PI ace 

Hartford, Connecticut 06156 
(203) 275-2012 

MEMBER AT LARGE 
Jim Redfield 
BDM 

9020 N. Cap. of Texas Highway 
Austin. TX 78759 
(512) 346-6760 

STORE REPRESENTATIVE 
FIMS STANDARDS REP. 

Paul W. Plum. Jr 
Lukens Steel Company 
Coatesville, PA 19320 
(215) 383-2024 

RMS WORKING GROUP COORDINATOR 

Allen Jay Bennett 
Logisticon, Inc. 

5035 Whitneyville Road 
Ada, MI 49301 
(616) 452-1823 
DEC COUNTERPART 
Wendy Herman 
John Wood 
Nashua, NH 



EDUSIG 

CHAIRMAN 

Robert A.Shive, Jr. 
Millsaps College 
Jackson, MS 39210 
(601) 354-5201 


SYMPOSIA COORDINATOR 

Mary Jac Reed 
Off Comp Based Instruction 
University of Delaware 
305 Willard Hall 
Newark. DE 19716 
(302) 451-8161 

COMMUNICATIONS REPRESENTATIVE 

Robert W. McCarley 
Millsaps College 
Jackson, MS 39210 
(601) 354-5201 
NEWSLETTER EDITOR 
Fred Bell 
Taft College 
29 Emmons Park Drive 
P.O. Box 1437 
Taft CA 93267 
(805) 763-4282 
PSS COORDINATOR 
VAX SYSTEMS SIG LIAISON 
Donald C. Fuhr 
Tuskegee Institute 
Tuskegee Institute. AL 36088 
(205) 727-8242 

ADMINSTRATIVE APPLICATIONS COORD. 

Dave Cothrun 
Taft College 
29 Emmons Pk Drive 
P.O. Box 1437 
Taft CA 93268 
(805) 763-4282 

SESSION NOTE EDITOR 
Paula Barnes 
Guilford College 
5800 West Friendly Avenue 
Greensboro. NC 17410 
(919) 292-5511 
DEC COUNTERPART 
Gary Finerty 
Marlboro, MA 

O Graphics 
Applications 

DECUS 

GRAPHICS APPLICATIONS SIG 

CHAIRMAN 

Bijoy Misra 

Smithsonian Institution 
60 Gordon St. MS39 
Cambridge, MA 02138 
(617) 495-7392 

SESSION NOTE EDITOR 

Carol Schwob 
Florida Atlantic Univ. 

Bldg. 22. Room 106 
Boca Raton, FL 33431 
(305) 393-2640 

NEWSLETTER EDITOR (acting) 

OPEN 

ASSOCIATE NEWSLETTER EDITOR 

Charles D. Carter 
Huntington Alloys, Inc. 

Technology Dept 
P.O. Box 1958 
Huntington, WV 25720 
(304) 526-5721 

WORKSTATION WORKING GROUP COORD. 

Bob McCormick 

Video Communications, Inc. 

1325 Springfield Street 
Feeding Hills, MA 01030 
(413) 786-7955 

ENGINEERING GRAPHICS WORKING GROUP COORD. 
Eric Rehm 
Gonzaga University 
SPOCAD 
E 502 Boone 
Spokane, WA 99258 
(509) 484-6814 


COMMUNICATIONS REP 
NEWSLETTER EDITOR 

Robert Hays 
KMS Fusion 
3621 So. State Road 
Box 1567 

Ann Arbor, MI 48106 
LIBRARY COORDINATOR 

Mike McPherson 
Michigan University 
269 Engineering Bldg. 

East Lansing, MI 48824 
(517) 353-9769 

STANDARDS COORDINATOR 

OPEN 

VOLUNTEER COORDINATOR 

Dick McCurdy 
University of Florida 
Room 216, Larsen Hall 
Gainsville. FL 32611 
(904) 392-4915 
LIBRARY COMMITTEE 
James M. Turner 
Saber Technology 
San Jose, CA 
DEC COUNTERPART 
Jim Flatten 
Spit Brook. NH 
Rick Landau 
Marlboro. MA 

INFORMATION OFFICER 

Mike York 

Boeing Computer Services 
P.O. Box 24346 M/S 03-73 
Seattle. WA 98124 
(206) 342-1442 

SYMPOSIUM COORDINATOR 

Dottie Elliott 
Northrop Services Inc. 

P.O. Box 12313 

Research Triangle PK. NC 27709 
(919)541-1300 

DATA DISPLAY WORKING GROUP COORD. 

Joy Williams 
Eaton Corp. 

P.O. Box 766 
Southfield, MI 48037 

HARD 

NEWS 

HARDWARE MICRO SIG 

CHAIRMAN 

Willian K. Walker 
Monsanto Research Corp. 

Miamisburg, OH 

PRODUCT PLANNING COORDINATOR 

George Hamma 
Synergistic Technology 
Cupertino. CA 

PRE SYMPOSIUM SEMINAR COORDINATOR 

James R. Lindesmith 
Monsanto Research Corp. 

Miamisburg, OH 

COMMUNICATIONS COORDINATOR 

John G. Hayes 
Information Systems 
South Central Bell 
Birmingham, AL 
NEWSLETTER EDITOR 

Carmen D. Wiseman 
Digital Review 
Boston, MA 

SESSION NOTE EDITOR 
DAARC SIG LIAISON 

Bill Tippie 

Kinetic Systems Corp. 

Lockport, IL 
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STANDARDS COORDINATOR 

CAMAC WORKING GROUP COORDINATOR 

Peter Clout 

Los Alamos National Lab 
los Alamos, NM 
LUG COORDINATOR 
Gregg Giesler 
Los Alamos Science Lab 
Los Alamos, NM 
TOEM (CHIPS & BOARDS) 

Jack J. Peterson 
Horizon Data Systems 
Richmond, VA 

HHK (HARDWARE HINTS & KINKS) 

Wayne Kesling 
Monsanto Research Cor. 

Miamisburg. OH 

UNIBUS HARDWARE 

Ron Bogue 

LIV Aerospace & Defense Co. 

Dallas, TX 

PERFORMANCE MEASUREMENT COORD. 

William Wallace 

600 W. Washington Street 

Peoria, IL 

CSS COORDINATOR 

Pratap Gohel 
E.I. duPont 
Ingleside, TX 

NETWORKS SIG LIAISON 

Sandra Traylor 
Target Systems 
Yorba Linda, CA 
VAX SIG LIAISON 
Dave Schmidt 
5100 Centre Avenue 
Pittsburgh, PA 
UNISIG LIAISON 

Jim Livingston 
1 Results Way 
Cupertino, CA 
SITE SIG LIAISON 
Emily Kitchen 
A.H. Robins Co. 

Richmond, VA 
RT-11 SIG LIAISON 
Gary Sallee 

Sallee Software Consulting 
yorba Linda, CA 
RSX SIG LIAISON 
Hans Jung 
Associated Press 
New York, NY 
MEMBERS-AT-LARGE 
Mike Rembis 
American Dade 
Costa Mesa, CA 
Hans Dahlke 
Richland, WA 
Jim Cutler 
EDS Tower 
16533 Evergreen 
Southfield, MI 

DEC COUNTERPARTS TERMINALS 
Nina Abramson 
Maynard, MA 
TOEM (Chips & Boards) 

Art Bigler 
Marlboro, MA 
DIAGNOSTIC 

George D. Cooke 
Maynard, MA 
STORAGE 

Marilyn Fedele 
Maynard, MA 

MSD (Micro Systems Develp.) 

Roy Rodgers 
Maynard, MA 
PRINTER PRODUCTS 
Frank Orlando 
Maynard, MA 

DECUS EUROPE LIAISON 

Hans Zoller 



IAS SIG 
CHAIRMAN 

Alan Frisbie 

Flying Disk Systems, Inc. 

4759 Round Top Drive 
Los Angeles, CA 90065 
(213) 256-2575 
NEWSLETTER EDITOR 
Frank R. Borger 
Radiation Therapy 
Michael Reese Medical Center 
Lake Shore Drive (© 31st St 
Chicago, IL 60616 
(312) 791-2515 

WHIMS COORDINATOR 
Kathleen Anderson 
Eaton Information Management 
System Division 
Hampton, VA 
(804) 326-1941 
RSX LIAISON 

Ray French 

Boeing Computer Services 
Seattle, WA 
(206) 655-6228 
MEMBER-AT-LARGE 
Doug Reno 
Abbot Laboratories 
North Chicago, IL 
(312) 937-7504 
PAST CHAIRMAN 

Mike Robitaille 
Grumman - CTEC, Inc. 

6862 Elm Street 
McLean VA 22101 
(708) 556-7400 x431 
CHAIRMAN EMERITUS 
Bob Curley 

Division of Medical Physics 
University of Pennsylvania 
Philadelphia, PA 
(215) 662-3083 

SYMPOSIA COORDINATOR 
Lynda L. Roenicke 
Special Systems Branch 
Naval Ocean Systems Center 
271 Cataline Blvd Code 742 
San Diego, CA 
(619) 225-7569 

LIBRARY COORDINATOR 

Ted Smith 

The University of PA 
Philadelphia, PA 19101 
(215) 662-3500 
MEMBER-AT-LARGE 
Kerry Wyckoff 
Salt Lake City, UT 
DEC COUNTERPART 

Nancyfaye Autenzio 
Stow, MA 
(617) 496-9606 



LANGUAGES AND TOOLS SIG 

CHAIRMAN 

Sam Whidden 

American Mathematical Society 
201 Charles St 
P.O. Box 6248 
Providence, RI 02940 
(401) 272-9500 
VICE CHAIR 

SYMPOSIA COORDINATOR 

Earl Cory 

Eaton Corporation 

31717 La Tienda Dr. 

Westlake Village, CA 91359 
(818) 706-5385 

STORE REPRESENTATIVE 
Chair, TECH. PROD OF DOC. W/G 
Howard Holcombe 
RCA 

Front & Cooper Sts. 

Camden, NJ 08055 
(609) 338-4946 
NEWSLETTER EDITOR 
ALT. CommComm REP. 

A1 Folsom. Jr. 

Fischer & Porter Co. 

E. County Line Rd. 

Warminster. PA 18974 
(215) 674-7154 

SESSION NOTES EDITOR 

Mark Katz 

GTE Government Systems 
100 First Avenue 
Waltham. MA 02154 
(617) 466-3437 

AUSTRALIAN L&TINTERFACE 

Gordon Brimble 
Bldg. 180 Labs Area 
Defence Research Centre 
Box 2151 GPO 

Adelaide, S.A. Australia 5001 
(61)(8)259-6119 

INTERSIG COORDINATOR 

Dorothy Geiger 
Wollongong Logistics Group 
49 Showers Drive #451 
Mountain View, CA 94040 
(415) 948-1003 
(415) 962-7160 
EUROPEAN METHODS 
L&TINTERFACE 
Bernd Gliss 
Max-Planck-Institute 
Heisenbergstra Be 1 
7000 Stuttgart 80, W. Germany 
(711) 686-0251 
PAST CHAIR 

PRODUCTIVITY TOOLS COORDINATOR 

Kathy Hornbach 
Digital Equipment Corporation 
110 Spit Brook Rd., ZK03-3/Y25 
Nashua, NH 03062 
(603) 881-2505 

CHAIR TECO WORKING GROUP 

Mark J. Hyde 

Advanced Computing Services 
209 Ardsley Drive 
DeWitt, NY 13214 
(315) 446-7223 

MEMBER, ANSI BASIC X3J2 STDS, COMM. 
STANDARDS COORD. 

PDP-11 REP. 

CHAIR, PDP-11 LAYERED PRODUCT W/G 

Stephen C. Jackson 
SCJ Consulting, Inc. 

7260 University Avenue N.E. 

Suite 105 

Minneapolis, MN 55432 
(612) 571-8430 
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CHAIR, CONFIG. MGMT. WORKING GROUP 
Mark Alan Kidwell 
Texas Instruments Inc. 

P.0. Box 869305 M/S 8435 
Plano. TX 75086 
(214) 575-3547 

DEVEL. COUNTERPART, PDP-11 SOFTWARE 

Joe Mulvey 

Digital Equipment Corp. .ZK01-3/J10 
110 Spit Brook Road 
Nashua. NH 03062-2642 
(603) 881-1218 

LISP/AI COORDINATOR 

Don Rosenthal 

Space Telescope Science Institute 
Homewood Campus 
Baltimore. MI) 21218 
(301) 338-4844 

LIBRARY REPRESENTATIVE 

SIG TAPE LIBRARIAN 

CHAIR, PUBLIC DOMAIN SOFTWARE W/G 

Tony Scandora 

Argonne National Laboratory 

C'MT 205 

Argonne, IL 60439 
(312) 972-7541 

CHAIR, C WORKING GROUP 

James Maves 
Eaton Corp, IMSD 
31717 La Tienda Drive 
Box 5009 

Westlake Village. CA 91359 
(818) 706-5395 
COMMCOMM REP. 

Jay Wiley 
Bechtel Power Corp 
12400 East Imperial Highway 
Norwalk, CA 90650 

(213) 807-4016 

SESSION CHAIRS COORDINATOR 
BOF CHAIRS COORDINATOR 
SESSIONS QUALITY COORD. 

ALT. SYMPOSIUM COORD. 

Gary C. Lelvis 
IMSL 

2500 Park West Tower One 
2500 City West Blvd. 

Houston, TX 77042-3020 
(713) 782-6060 

CHAIR, FORTRAN WORKING GROUP 

Scott Krusemark 

8473 Daisywood Ave N.W. 

North Canton, OH 44720 
(216) 499-6251 

CHAIR, LOW LEVEL LANGUAGES W/G 

Gerald Lester 

Computerized Processes Unlim. 

2901 Houma Blvd. Suite 5 
Metairie, LA 70006 
(504) 889-2784 

DEVEL COUNTERPART, COMM. LANG. 

Jim Totton 

Digital Equipment Corp. 

ZK02-3/K06 

110 Spit Brook Road 

Nashua, NH 03062 

ALT. ANSI X3J9 PASCAL STDS. COMM. 

Phil Wirth 

E-Systems, Garland Division 
Box 660023, MS 53730 
Dallas. TX 75266-0023 

(214) 272-0515 x4319 

ALT. ANSI X3J4 COBOL STDS. COMM. 

Dale Marriott 

El Paso County Office Bldg. 

27 E. Vermijo Street 
Colorado Springs, CO 80903 
(303) 520-6435 

CHAIR, DIBOL WORKING GROUP 

ASSOC, W/G COORD. UNSCHEDULED TOPICS 

ACTING CHAIR, COBOL WORKING GROUP 

Bruce Mebust 

Burlington Northern Railroad 
176 East Fifth Street 
P.O. Box 64962 
St. Paul. MN 55164 
(612) 298-2382 


CHAIR, SECURITY WORKING GROUP 

Rich Harris 

General Research Corp. 

5383 Hollister Avenue 
P.O. Box 6770 

Santa Barbara, CA 93160-6770 
(805) 964-7724 

ASSISTANT CAMPGROUND COORD. 

Tom J. Jeffrey 

Rockwell International Corp. 

1225 N. Alma Road 
Richardson. Texas 75081 
(214) 996-7818 

CHAIR, ADA WORKING GROUP 

Lisa Kerby-Rodgers 
GTE Government Systems 
100 Ferguson Drive 
P.O. Box 7188 
Mountain View, CA 94039 
(415) 966-2720 

CHAIR, PROJECT MANAGEMENT W/G 

Lynn C. Lewis 

Lawrence Livermore National Lab. 
University of California 
P.O. Box 808 
Livermore, CA 94550 
(415) 422-8949 

TEMP. CHAIR, OBJ. ORIENTED DES. W/G 
Frank B. Modruson 
Arthur Andersen & Co. 

33 West Monroe Street 
Chicago. IL 60603 
(312) 580-0033 

CHAIR, TeX/LaTEX WEB W/G 

John Osudar 
Argonne National Lab. 

9700 South Cass Avenue 
Argonne. IL 60439 
(312) 972-7505 
CHAIR, VAXset W/G 
David J. Powell 
The Upjohn Company 
7263-267-712 
301 Henrietta St 
Kalamazoo, MI 49007 
(616) 344-3341 

MEM., ANSI DIBOL X3J12 Stds. Comm. 
Kenneth Schilling 
2314 Mira Vista Avenue 
Montrose. CA 91020 
(818) 249-0795 

SUITE & RECEPTION COORD. 

Matt Variot 
Eaton Corporation 
Box 5009 

31717 La Tienda Drive 
Westlake Village, CA 91359 
(818) 706-5388 

CHAIR, TPU/EVE/LSE W/G 
John Wilson 
Aetna Life & Casualty 
City Place YFB3 
Hartford, CT 06103 
(203) 275-2064 
VICE CHAIR 

SYMPOSIUM LOGISTICS COORD. 

Terry Medlin 
Survey Sampling. Inc. 

1 Post Road 
Fairfield CT 06432 
(203) 255-4200 

MASTERS COORDINATOR 

Dena Shelton 
Cullinet Software Inc. 

2860 Zanker Rd, Suite 206 
San Jose. CA 95134 
(408) 434-6636 

ACTING CHAIR, APL WORKING GROUP 
CHAIR, BASIC W/G 
WISHLIST COORDINATOR 

Bob Van Keuren 
UserWare International, Inc. 

2235 Meyers Ave. 

Escondido. CA 92025 
(619) 745-6006 


WORKING GROUPS COORD. 
CAMPGROUND COORDINATOR 

Joseph Pollizzi, III 
Space Telescope Science Institute 
3700 San Martin Drive 
Homewood Campus 
Baltimore, MD 21218 
(301) 338-4901 

CHAIR, SCAN WORKING GROUP 
CHAIR, PL/1 WORKING GROUP 
VOLUNTEERS COORD. 

David Ream 
Lexi-Comp 

26173 Tallwood Drive 
N. Olmsted, OH 44070 
(216) 777-0095 
(216) 468-0744 

CHAIR, PASCAL WORKING GROUP 
MEMBER, ANSI PASCAL X3J9 STDS. COMM. 
CHAIR, MODULA-2 W/G 
E. Wayne Sewell 
E-Systems, Garland Div. 

Box 660023, MS 53700 
Dallas, TX 75266-0023 
(214) 272-0515 x3553 

CHAIR, SOFTWARE METRICS W/G 

Michael S. Terrazas 
LDS Church 

50 E. North Temple, 27th Floor 
Salt Lake City. UT 84150 
(801) 531-3246 

MEMBER, ANSI COBOL X3J4, STDS, COMM. 

Bruce Gaarder 
Donahue Enterprises. Inc. 

2441 26th Ave., S. 

Minneapolis. MN 55406 
(612) 721-2418 

ALT. SEMINAR COMM REP. 

Janet E. Bressan 
Boeing Aerospace Co. 

P.O. Box 3999, MS3C-24 
Seattle, WA 98124 
(206) 773-9404 

CHAIR, RPG WORKING GROUP 

Charles Williamson 
Hargray Telephone Co. 

P.O. Box 5519 

Hilton Head Is.. SC 29938 

(803) 686-1204 

SEMINAR COMMITTEE REP. 

Barry C. Breen 

Sundstrand Data Control, Inc. 

15001 N.E. 36th Street 
P.O. Box 97001 
Redmond, WA 98073-9701 
(206) 885-8436 

ASSIST. MASTERS COORD. 

CLINIC DIRECTOR 

CHAIR, CASE & TOOLS INTEGRATION W/G 

George Scott 
Computer Sciences Corp. 

304 West Route #38, P.O. Box N 
Moorestown, NJ 08057 
(609) 234-1100 

ASSISTANT CAMPGROUND COORD. 

Keith Batzel 
Crowe, Chizek & Co. 

330 E. Jefferson 
Box 7 

South Bend, IN 46624 
(219) 232-3992 

DEVEL. COUNTERPART TECH. LANG. 

Leslie J. Klein 
Digital Equipment Corp. 

ZK02-3/N30 
110 Spit Brook Road 
Nashua. NH 03062 
DIGITAL COUNTERPART 
Celeste La Rock 
Digital Equipment Corp. 

ZK02-3/Q08 

110 Spit Brook Road 

Nashua. NH 03062 
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LARGE SYSTEMS 

CHAIR 

E.F. Berkley Shands 
Washington University 
Department of Computer Science 
P.0. Box 1045 
St. Louis. MO 63136 
(314) 889-6636 

UUCP: BERKLEYS WUCS.UUCP 
BITNET: Berkleys Uunet 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Clyde T. Poole 

The University of Texas at Austin 
Department of Computer Sciences 
Taylor Hall 2.124 
Austin. TX 78712-1188 
(512) 471-9551 

ARPANET/CSNET:ctpfa sally.utexax.edu 
36 BIT SYSTEMS 

Clive Dawson 

Microelectronics & Computer Technology Corp. 

9430 Research Blvd. 

Echelon Bldg. #1. Suite 200 
Austin. TX 78759 
(512) 343-0860 

A RPANET/CSNET: CLIVE <n MCC. COM 

SYMPOSIUM REPRESENTATIVE 

Vacant 

DISTRIBUTED SYSTEMS 

Don Kassebaum 
Computation Center 
University of Texas at Austin 
Austin, TX 78712 
(512) 471-3241 

ARPANET:CC.KASSEBAUM(« A20.CC.UTEXAS.EDU 
SEMINARS REPRESENTATIVE 
Robert C. McQueen 
(201) 428-4242 

ARPANET: SIT. MCQUEEN^ cu20B.COLUMBIA.EDU 

SUPERCOMPUTING 

Vacant 

SIG VICE-CHAIRMAN 

Ralph M. Bradshaw 
Johnson & Johnson 
Research & Scientific Services 
Management Information Center 
Raritan. NJ 08869-1489 
(201) 685-3434 

LIBRARY REPRESENTATIVE 
SIR/MENU BALLOT 

Jack Stevens 
The Gillette Company 
Technical Services. 4U-3 
1 Gillette Park 
Boston, M A 02106-2131 
(617) 463-2089 
SIG MARKETING 
Steve Attaya 
Weiner Enterprises 
P.O. Box 23607 
Harahan, LA 70183 
(504) 733-7055 

ARPANET:G.ATTAYAffi R20.UTEXAS.EDU 
CORPORATE ISSUES 
Ralph Bradshaw 
Johnson & Johnson 
Research and Scientific Services 
Management Information Center 
Raritan. NJ 08869-1489 
(201) 685-3434 
DEC COUNTERPARTS 
Dave Braithwaite 
Digital Equipment Corporation 
Marlboro. MA 
Rich Whitman 

Digital Equipment Corporation 
Marlboro, MA 
Reed Powell 

Digital Equipment Corporation 
Marlboro, MA 



MUMPS SIG 

CHAIRMAN 

Chris Richardson 
Richardson Computer Research 
P.O. Box 8744 
La Jolla. CA 92038 
(619) 488-6193 
NEWSLETTER EDITOR 
VICE-CHAIR 
COMMCOMM REP. 

Mark J. Hyde 

Advanced Computing Services 

209 Ardsley Drive 

DeWitt, NY 13214 

BITNET: MJHYDE<«'SUNRISE 

INTERNET: MJHYDEfffSUNRISE.ACS.SYR.EDU 

(315) 446-7223 

SYMPOSIUM SCHEDULER 

Brad Hanson 
Group Health, Inc. 

2829 University Ave., S.E. 

Minneapolis, MN 55414 
(612) 623-8427 

LIBRARY REPRESENTATIVE 
PD P-11 WORKING GROUP REP. 

Michael McIntyre 
PRx, Inc. 

43 Bradford Street 
Concord, MA 01742 
(617) 369-3566 

SEMINARS REPRESENTATIVE 

Edward Woodward 
Science Applications Inti. Corp. 

10260 Campus Point Drive MS42 
San Diego. CA 92121 
(619) 535-7210 

CAMPGROUND COORDINATOR 
ASSIST. SYMPOSIUM SCHEDULER 
Jerry Hsu 
Rubicon Corp. 

1200 E. Campbell 
Richardson, TX 75083 
(214) 231-6591 

SESSION NOTES EDITOR 

Paul A. Price 
SciCor, Inc. 

2643 Rand Road 
Indianapolis, IN 46241 
(317)244-8811 
PAST CHAIR 

MUMPS DEV. COMMITTEE REP. 

Mark Berryman 
Digital Equipment Corp. 

3 Results Way (MR03-2/H7) 

Marlborough. MA 01752 
(617) 467-4875 

BITNET: BERRYMAN^DSM.DEC.COM 
DEC COUNTERPART 
Dave Smith 

Digital Equipment Corp. 

2 Iron Way (MR03-2/H7) 

Marlborough. MA 01752 
(617) 467-2397 

ALTERNATE DEC COUNTERPART 

Denise Simon 
Digital Equipment Corp. 

129 Parker Street (PK02-1/M23) 

Maynard. MA 01754 
(617) 493-9077 




NETWORKS SIG 

CHAIRMAN 

Stuart Lewis 
Douglas Furn. Corp. 

(312) 458-1505 

COMMUNICATIONS COMMITTEE REP. 
Bob Gustafson 
Northeast Utilities 
(203) 665-5082 
NEWSLETTER EDITOR 
Judi Mandl 

UCONN Health Center 
263 Farmington Ave. Bldg. 19 
Farmington, CT 06032 
SEMINAR UNIT REP & 

VICE (BACKUP) SIG CHAIR 
Sandy Traylor 
Target Systems, Inc. 

(714) 921-0112 

SYMPOSIA COORDINATOR 

Bill Hancock 
(817) 261-2283 

STANDARDS COORDINATOR 
Jim Ebright 
Software Results Corp. 

(614) 267-2203 

ASSISTANT NEWSLETTER EDITOR 
Judi Mandl 
UConn Health Center 
(203) 674-3912 

SESSION NOTES EDITOR 
Mary Marvel-Nelson 
General Motors Research Lab. 

(313) 986-1382 
DEC COUNTERPART 
Monica Bradlee 
(617) 486-7341 



OFFICE AUTOMATION SIG 

CHAIR 

Katherine “Kit” Trimm 
Pivotal, Inc 
Tucson, AZ 
(602) 886-5563 
VICE CHAIRMAN 

Ralph Bradshaw 
Johnson and Johnson 
Raritan, NJ 
(201) 685-3434 

COMMUNICATIONS REPRESENTATIVE 
Mary Jane Bolling 
Foreign Mission Board 
3806 Monument Avenue 
Richmond, VA 23230 
(804) 353-0151 

SYMPOSIA COORDINATOR 

Mitch Brown 
GenRad, Ind. 

Waltham, MA 
(617) 369-4400 x3052 
NEW MEMBER COORDINATOR 
Tricia Cross 

American Mathematical Society 
P.O. Box 6248 
Providence, RI 02940 
(401) 272-9500 
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BOF COORDINATOR 
Ray Kaplan 
PIVOTAL, Inc. 

Tucson, AZ 
(602) 886-5563 
NEWSLETTER EDITOR 
Therese LeBlanc 
T.M. LeBlanc & Assoc. 

Wheeling, IL 
(312) 459-1784 
LIBRARY 

Bob Hassinger 

Liberty Mutual Research Center 
Hopkington, MA 
(617) 435-9061 

OA TAPE COORDINATOR 

Mary Jane Boiling 
Foreign Mission Board 
3806 Monument Avenue 
Richmond, VA 23230 
(804) 353-0151 

SYMPOSIA ASSISTANT 

Sal Gianni 
Northeast Utilities 
Hartford, CT 
(203) 665-5652 

STORE COORDINATOR 

Mike Jackson 
Air Force Operational 
Test and Evaluation Center 
Kirtland AFB, NM 
(505) 846-5641 

PERSONAL COMPUTER SIG LIAISON 

Cheryl Johnson 
Grinnell College 
Grinnell, IA 
(515) 236-2570 

OA LUG COORDINATOR 

Tom Orlowski 

American Council on Education 
1 DuPont Circle (Suite 110) 
Washington, DC 
(202)939-9371 

OA SIG COORDINATOR 

Joe Whatley 
Neilson Media Research 
375 Patricia Avenue 
Dunedin, FL 33528 
(813)734-5473 

SESSION NOTE EDITOR 

George Bone 
194 Nalisty Drive 
Vallejo, CA 94590 
(707) 646-2531 



PERSONAL COMPUTER SIG 

CHAIR 

Lynn Jarrett 

San Diego Union-Tribune Pub. Co. 

350 Camino de la Reina 
San Diego, CA 92108 
(619) 293-1130 

WORKSTATIONS/MACS/PRO 
WORKING GROUP CHAIRMAN 

Thomas R. Hintz 
Univ. of Florida 
IFAS Computer Network, 

Bldg. 120 

Gainesville, FL 32611 
(904) 392-5180 

VICE, CHAIR RAINBOW W/G CHAIRMAN 

Lynn Jarrett 

Union Tribune Publishing Co. 

P.O. Box 191 
San Diego, CA 92108 
(619) 299-3131 xll30 


VAXMATE WORKING GROUP CHAIRMAN 

Frederick G. Howard 
Eastman Kodak Company 
901 Elmgrove Road. D345-LP 
Rochester, NY 14650 
(716) 253-2363 

VOLUNTEER COORDINATOR 

Pierre M. Hahn 
SUNY HSC-T10-028-8101 
Stony Brook, NY 11794 
LIBRARIAN Rep. 

Ron S. Hafner 
Hafner and Associates 
P.O. Box 2924 
2499 Wellingham Dr. 

Livermore. CA 94550 
(415) 422-2149 

COMMUNICATIONS REPRESENTATIVE 

Kenneth LeFebvre 
Sytek, Inc. 

19 Church St 
P.O. Box 128 
Berea, OH 44017 
(216) 243-1613 
NEWSLETTER EDITOR 
Gary Rice 
McDonnell Douglas 
5555 Garden Grove Blvd. 

MS: K200 77/200 
Westminster. CA 92683 
(714) 952-6582 

RAINBOW/DECmate W.G. CHAIR 
Vince Perriello 

Crosfield Composition Systems 
One Crosfield Ave. 

West Nyack, NY 10994 
(914) 353-4000 

SYMPOSIA COORDINATOR 

Jimbo Wilson 

Natl Tech. Inst for Deaf 

Rochester Inst of Tech. 

P.O. Box 9887 
Rochester, NY 14623 
(716) 475-6241 

SESSION NOTES EDITOR 

Dr. Tom. Warren 
Oklahoma State Univ. 

Dept of English 
Dir. Tech. Writing Program 
Stillwater, OK 74078 
(405) 624-6138 

PCS A WORKING GROUP CHAIRMAN 

To be announced 
MEMBERS-AT-LARGE 
Michael Bowers 
Univ. of California 
Animal Science Department 
Davis. CA 95616 
(916) 752-6136 
Theodore Needleman 
Odea Tech. 

67 W. Burda PI. 

Spring Valley, NY 10977 
(914) 250-100 

DEC COUNTERPARTS 

PERSONAL COMPUTING SYSTEMS GROUP 

Anita Uhler 

Digital Equipment Corporation 

LJ02/13 

30 Porter Road 

Littleton, MA 01460 

(617) 486-2397 

PRO 

Jeff Slayback 
Digital Equipment Corp. 

ML021-2/U12 
146 Main Street 
Maynard, MA 01754 
(617) 493-9340 

BUTTON COORDINATOR 

Ken Strieker 

Martin Marietta Aerospace 
P.O. Box 5837 MP 320 
Orlando. FL 32855 
(305) 356-6589 


CAMPGROUND COORDINATOR 

Jim Hobbs 
Adolf Coors Co. 

Golden. CO 80401-1295 
(303) 277-2855 

SEMINARS COORDINATOR 

Tim Bundrick 
3480 TCHTW/TTVC 
Goodfellow AFB.TX 76908-5000 
(915) 657-5424 



RSTS SIG 

CHAIRMAN 

Charles Mustain 
Stark County School system 
Data Services Division 
7800 Columbus Rd. N.E. 

Louisville, OH 44641 
(216) 875-1431 

COMMUNICATIONS REPRESENTATIVE 
STORE REPRESENTATIVE 

Ed Beadel 

Instructional Computer Center 
S.U.N.Y. College at Oswego 
Oswego, N.Y. 13126 
(315) 341-3055 

SYMPOSIA COORDINATOR 

Glenn Dollar 

Digital Computer Consultants Inc. 

21363 Lassen St, Suite 205 
Chatsworth, CA 91311 
(818) 341-9171 

ASST SYMPOSIA COORDINATOR 

Dan Stoller 

Natural Country Farms 
P.O. Box 758 
58 West Road 
Rockville. CT 06066 
(203) 872-8346 
NEWSLETTER EDITOR 

Terence M. Kennedy 
St Peter's College 
Department of Computer Science 
2641 Kennedy Blvd. 

Jersey City, NJ 07306 
(201) 435-1890 

LIBRARY REPRESENTATIVE 

RR. Patel (PAT) 

Krupp/TaylorUSA 
12800 Culver Blvd 
Los Angeles. CA 90066 

(213) 306-3646 

PRE SYMPOSIA SEMINAR COORDINATOR 

Scott Castleberry 
1750 North Collins 
Suite 108 

Richardson, TX 75080 

(214) 437-3477 
VICE CHAIRMAN 

WISH LISTS COORDINATOR 
Lynnell Koehler 
Campus America 
POISE Prod. Ctr. 

201 North Nevada Avenue 
Roswell, NM 88201 
(505)625-5500 
EDUSIG LIAISON 

George Wyncott 

Purdue University Computer Center 
W. Lafayette. IN 
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RSTS PRODUCT PLANNING COORDINATOR 

Errol E. Ethier 

Information Design and Management, Inc. 
23 Hunting Avenue 
(617) 842-4220 
Shrewsbury, MA 01545 
DEC COUNTERPART 
Kathy Waldron 

Digital Equipment Corporation 
Continental Blvd. 

Merrimack, NH 03054 
MEMBERS-AT-LARGE 

Edward F. Beadel Jr. 

Manager 

Instructional Computing Center 

S.U.N.Y. College at Osyvego 

Oswego, NY 13126 

(315) 341-3055 

Mark Hartman 

Jadtec Computer Group 

546 W. Katella Avenue 

Orange, CA 92667 

(714) 997-8928 

Jeff J. Killeen 

Information Design & Management, Inc. 

31 Hopedale Street 
Hopedale, MA 01747 
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| HU* t«M 

I 


RSX SIG 

CHAIRMAN 

Dan Eisner 
Perkin-Elmer Corp. 

Garden Grove, CA 
SYMPOSIA COORDINATOR 
Rick Sharpe 
Toledo Edison 
Toledo, OH 

PRE-SYMPOSIUM SEMINAR COORDINATOR 

Hans Jung 
Associated Press 
New York, NY 

COMMUNICATIONS REPRESENTATIVE 

Jay Allen Bennett 
Logisticon, Inc. 

5035 Whitneyville Road 
Ada, MI 49301 
(616) 452-1823 
NEWSLETTER EDITOR 

MULTI PROCESSORS WORKING GROUP COORDINATOR 

Bruce Mitchell 

Machine Intelligence & Industry Magin 
Byron, MIN 

STORE COORDINATOR 

Jim Hopp 

Carlton Financial Computation 
South Bend, IN 
SESSION NOTE EDITOR 
Burt Janz 
BHJ Associates 
Nashua, NH 
LIBRARIAN 

Glenn Everhart 
Mt. Holly. NJ 

CAMPGROUND COORDINATOR 

Jerry Ethington 
Prolifix Inc. 

Frankfort, KY 
DEC COUNTERPARTS 
Lin Olsen 
Nashua, NH 


WORKING GROUP CHAIR 

Evan Kudlajev 
Philadelphia Electric Co. 

Philadelphia, PA 

RSX GROUP CHAIR SOFTWARE CLINIC COORD. 

Roy S. Maull 
U.S. Air Force 
Offutt AFB, NE 

SOFTWARE CLINIC COORDINATOR 

Bruce Zielinski 
RCS 

Moorestown, NJ 

VOLUNTEER COORDINATOR 

Gary Maxwell 

U.S. Geological Survey 

Menlo Park, CA 

SRD WORKING GROUP COORDINATOR 

Bob Turkelson 

Goddard Space Flight Center 
Greenbelt, MD 

ACCOUNTING & PERFORMANCE WORKING GROUP COORD. 

Denny Walthers 
American McGaw 
Irvine, CA 

MENU COORDINATOR 

Ed Cetron 

Center for Biomedical Design 
Salt Lake City, UT 
MEMBERS-AT-LARGE 
Jim McGlinchey 
Warren ton, PA 
Jim Neeland 
Hughes Research Labs. 

Malibu, CA 

Anthony E. Scandora, Jr. 

Argonne National Laboratory 
Argonne, IL 
Ralph Stamerjohn 
Creve Coeur, MO 



RT-11 SIG 

CHAIRMAN 

John T. Rasted 
JTR Associates 
58 Rasted Lane 
Meriden, CT 06450 
(203) 634-1632 

COM. COM VOTING REP. 

COBOL CONTACT 
Bill Leroy 

The Software House, Inc. 

P.O. Box 52661 
Atlanta, GA 30355-0661 
(404) 231-1484 

STANDARDS COORDINATOR 

Robert Roddy 
Naval Ship Research Ctr. 
Bethesda, MD 20084 
(301) 227-1724 
MACRO CONTACT 

Nick Bourgeois 
NAB Software Services Inc. 
P.O. Box 20009 
Albuquerque, NM 87154 
(505) 298-2346 
NEWSLETTER EDITOR 
TECO CONTACT 
PRODUCT PLANNING CONTACT 
John M. Crowell 
Multiware, Inc. 

2121-B Second St Suite 107 
Davis, CA 95616 
(916) 756-3291 


Dick Day 
Nashua. NH 

WORKING GROUP COORDINATOR 

Sharon Johnson 
Epidemiology 
Minneapolis, MN 


NETWORKING CONTACT 

Jim Crapuchettes 
Omnex Corp. 

2483 Old Middlefield Way 
Mountain View, CA 94043 
(415) 966-8400 
WISH LIST CONTACT 
UNIX/ULTRIX CONTACT 
Bradford Lubell 
LA. Heart Lab, UCLA 
10833 Le Conte Avenue 
Los Angeles, CA 90024-1760 
(213) 206-6119 
TSX & C CONTACT 
Jack Peterson 
Horizon Data Systems 
P.O. Box 29028 
Richmond, VA 23229 
(804) 740-9244 
RUNOFF CONTACT 
John Davis 

Naval Ship Research Center 
Code 2950 

Bethesda. MD 20084 
(301) 227-1592 
LUG CONTACT 

Ned Rhodes 

Software Systems Group 
2001 North Kenilworth St 
Arlington, VA 22205 
(703) 534-2297 

PERSONAL COMPUTERS 

Dennis V. Jensen 
AMES Labs. ISU/USDOE 
310 Metallurgy 
Ames, Iowa 50011 
(515) 294-4823 

SYMPOSIA COORDINATOR 
Milton Campbell 
Talisman Systems 
Drawer CP-255 
Manhattan Beach, CA 90266 
(213) 318-2206 

TAPE COPY GENERATION 
TAPE COPY DISTRIBUTION 
RT DECUS LIBRARY CONTACT 
Tom Shinal 
Syntropic Technology 
P.O. Box 198 
Waterford, VA 22190 
(703) 882-3000 

PRE-SYMPOSIUM SEMINAR 
RT-11 SUITE MANAGER 
Bruce Sidlinger 
Sidlinger Computer Corp. 
4335 N.W. Loop 410, #209 
San Antonio, TX 78229 

(512) DIG-ITAL 
BASIC CONTACT 

Ralston Barnard 
Div 7523 
Sandia Labs 

Alburquerque, NM 87185 
(505) 844-5115 

PRO RT-11 & HARDWARE 

Bill Walker 

Monsanto Research Corp. 
P.O. Box 32, A-152 
Miamisburg, OH 45342 

(513) 865-3557 
FORTRAN CONTACT 

Robert Walraven 
Multiware, Inc. 

2121-B 2nd St. Suite 107 
Davis, CA 95616 
(916) 756-3291 
OTHER LANGUAGES 
Gary Sallee 
19912 Fernglen Drive 
Yorba Linda, CA 92686 
(714) 970-2864 
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SITE SIG 

CHAIRMAN 

Timothy Fraser 

Specialized Bicycle Components 
15130 Concord Circle #77 
Morgan Hill, CA 95037 
(408) 779-6229 

SYMPOSIA COORDINATOR 

Sue Abercrombie 
48 Malilly Rd. 

Portland, ME 04103 
(207) 772-2837 

SESSION NOTE EDITOR 
LARGE SYSTEMS SIG LIAISON 

Gary Bremer 
Emerson Electric Co. 

8100 W. Florisant 
St. Louis, MO. 63136 
(314) 553-4448 
NEWSLETTER EDITOR 
NETWORKS SIG LIAISON 
OA SIG LIAISON 

Gregory N. Brooks 
Washington University 
Behavior Research Labs 
1420 Grattan St. 

St Louis, MO. 63104 
(314) 241-7600 ext 257 
HARDWARE COORDINATOR 
HMS SIG Liason 
Emily Kitchen 
A.H. Robins Co. 

1211 Sherwood Ave. RT-2 
Richmond. VA. 23220 
(804) 257-2925 

COMMUNICATIONS COMMITTEE REPRESENTATIVE 
AI SIG Liason 

Terry C. Shannon 
Digital Review 
160 State St. 

6th Floor 

Boston, MA. 02109 
(617) 367-7190 

PRE-SYMPOSIA SEMINAR COORDINATOR 

Phillip Ventura 
STAFF MANAGEMENT 
Adam Zavitski 
Simmonds Precision ICD 
3100 Highland Blvd. 

Raleigh, NC. 27625 
(919) 872-9500 
MEMBERS-AT-LARGE 
Ann Goergen 
Texas Instruments 
13510 N. Central 
M/S 437 

Dallas, TX. 75266 
(214) 995-4629 

HMS SIG Liason 
RT SIG Liason 

David Hunt 

Lawrence Livermore National Lab 

MS L-230 

P.O. Box 808 

Livermore CA. 94550 

(802) 656-3190 

Gary Siftar 

Digital Equipment Corporation 
Tulsa, OK. 

DEC COUNTERPARTS 
Joe Allen 
Stow MA. 

Lil Holloway 
Bedford MA. 

Susan Porada 
Marlboro, MA. 



UNISIG 

CHAIRMAN 

Kurt L. Reisler 
Hadron Incorporated 
9990 Lee Highway 
Fairfax. VA 22030 
(703) 359-6100 
decvax Iseismo! hadron !klr 
SYMPOSIA COORDINATOR 
Stephen M. Lazarus 
Ford Aerospace & Communications 
3939 Fabian Way. MS X-20 
Palo Alto. CA 94303 
(415) 852-4203 
ihnp4!fortune!wdll!sml 
SESSION NOTES EDITOR 
William Cheswick 
New Jersey Institute of Tech. 
Computing Seivices 
323 Martin Luther King Blvd. 
Newark, NJ 07102 
(201) 596-2900 
bellcore!njitcccc!bc 
NEWSLETTER EDITOR 

Sharon Gates-Fishman 
NIK' Corporation 
730 E Cypress Avenue 
Monrovia, CA 91016 
(818) 358-1871 
!amdahl!cit-vax!ndc!sgf 
COMMCOMM REPRESENTATIVE 
James W. Livingston. Jr. 

Measurex Automation Systems 
10411 Bubb Rd 
Cupertino. CA 95014-4150 
(408) 973-1800 x 766 
ihnp4!masl!jwl 

ADMINISTRATIVE DAEMON 

Dorothy A. Geiger 
The Wollongong Group 
49 Showers Drive, #451 
Mountain View. CA 94040 
(415) 948-1003 
ihnp4! decwrl Mgeiger 
TAPE LIBRARIAN 

Carl Lowenstein 

Marine Physical Laboratory 

Scripps Institute of Oc'graphy. P-004 

LaJolla. (’A 92093 

(619) 294-3678 

|ihnp4.docvax.akgua,dcdwest.ucbvax| 
Isdcsvax !mplvax!cdl 
USENET LIAISON 
STANDARDS COORDINATOR 
Ed Gould 
Ml. Xinu 
2910 7th St. 

Suite 120 
Berkley.('A 94710 
(415)644-0146 
ucbvax!mtxinu!ed 

MINISTER WITHOUT PORTEOLIO 

Norman Wilson 
Bell Laboratories. 2C-529 
600 Mountain Avenue 
Murray Hill. NJ 07974 
(201) 582-2842 

| decvax.ihnp4|! research! norman 
SEMINARS COORDINATOR 
Steven Step an ek 
Computer Science Dept. 

School of Eng. & Computer Science 
18111 NordhoffSt. 

Northridge. CA 91330 
(818) 885-2799 or 3.398 
ihnp4!csun !sgs 


DEC COUNTERPART 

Gary Oden 

Digital Equipment Corporation 
Continental Blvd. MK02 
Merrimack. NH 03054 
(603) 884-5111 
decvax!oden 



VAX SYSTEMS SIG 

SYMPOSIUM COORD., ASSISTANT 

David Cossey 
Computer ('enter 
Union College 
Schenectady, NY 12308 

SESSION NOTES EDITOR 

Ken Johnson 

Meridien Technology Corp. 

P.O. Box 2006 
St. Louis, MO 63011 
NEWSLETTER EDITOR 
Clyde Poole 
Univ. Texas/Austin 
Dept, of Computer Science 
Taylor Hall 2,124 
Austin, TX 78712-1188 
(512) 471-9551 

LIBRARY WORKING GROUP 

Glen Everhart 
25 Sleigh Ride Road 
Glen Mills, PA 19342 
VAXcluster WORKING GROUP 
Thomas Linscomb 
Computation Center 
University of Texas 
Austin. TX 78712 

NETWORK WORKING GROUP 

Bill Hancock 

Dimension Data Systems, Inc. 

P.O. Box 13557 
Arlington. TX 76094-0557 

MicroVAX WORKING GROUP 

Rav Kaplan 
Pivotal. Inc. 

6892 East Dorado Court 
Tucson. AZ 85715-3264 
(602) 886-5563 

SYSTEM IMPROVEMENT REQUEST (CORE) 

Mark I). Oakley 
Battelle Memorial Institute 
505 King Avenue 
Columbus. OH 43201-2669 

MULTIPROCESSOR WORKING GROUP 

Eugene Pal 
U.S. Army 

CAORA(ATORCATC) 

Fort Leavenworth. KA 

PRE-SYMPOSIUM SEMINAR COORD. HISTORIAN 

Jeff J albert 
JCC 

P.O. Box 381 
Granville. OH 43023 

PRE-SYMPOSIUM SEMINAR COORD. (ACTING) 

June Baker 

Computer Sciences Corp. 

6565 Arlington Blvd. 

Falls Church. VA 22046 

FIELD SERVICE WORKING GROUP 

Dave Slater 

Computer Sciences ('or)). 

6565 Arlington Blvd 
Falls Church. VA 22046 
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LARGE SYSTEMS INTEGRATION WORKING GP 

Leslie M altz 

Stevens Institute of Tech. 

Computer Center 
Hoboken, NJ 07080 
VOLUNTEER COORDINATOR 
Elizabeth Bailey 
222 CEB 

Tennessee Valley Authority 
Muscle Shoals. AL 85661 

COMMERCIAL WORKING GROUP 

Bob Boyd 

GE Microelectronics Center 
P.O. Box 18409. MS7T3-01 
Research Triangle Park. NC 27709-3049 
SECURITY 

C. Douglas Brown 
Sandia National Labs 
Division 2644 
P.O. Box 5800 

Albuquerque. NM 87185-5800 
MIGRATION AND HOST DEVELOPMENT 
VAXintosh WORKING GROUP 
Jim Downward 
KMS Fusion Incorporated 
P.O. Box 1561) 

Ann Ar or. Ml 48106 
REAL TIME/PROCESS CONTROL 
Dennis Frayne 
McDonnell Douglas 
5301 Bolsa Avenue 
Huntington Beach. CA 92646 
Lurry Robertson 
Bear Computer Systems 
56512 Case Avenue 
North Hollywood. CA 
INTERNALS WORKING GROUP 
Carl E. Friedberg 
Seaport Systems. Inc. 

165 William Street. 9th Floor 
New York. NY 10038-2605 
COMMUNICATIONS ASSISTANT 
David L.Wyse 

Professional Business Software 
3680 Wyse Road 
Dayton. OH 45414-2539 

CAMPGROUND COORDINATOR 

Kirk Kendrick 
Shell Oil ('o. 

333 Highway G. MS I>-2146 
Houston. TX 77082-8892 
PAST CHAIR 

Marge Knox 
Computation Center 
University of Texas 
Austin. TX 78712 
SYSTEM MANAGEMENT 
Steve Tihor 
251 Mercer Street 
New York. NY 10012 
ADVISORS 

Joseph Angelico 

U.S. Coast Guard Detachment 

National Data Buoy Center 

NSTL Station. MS 39529-6000 

Art McClinton 

Mitre 

1820 Dolle.v Madison Blvd. 

McLean. VA 22102 
A1 Siegel 

Battelle Memorial Institute 
505 King Avenue 
Columbus. OH 43201-2693 
CHAIR (CORE) 

Susan T. Rehse 

Lockheed Missiles & Space Co. 

0/19-50. B/101. P.O. Box 3504 
Sunnyvale. CA 94088-3504 
VICE-CHAIR (CORE) 

WORKING GROUP COORD. 

Ross Miller 

Online Data Processing Inc. 

N 637 Hamilton 
Spokane. WA 99202 


SYMPOSIA COORD. (CORE) 

Jack Cundiff 

Horry-Georgetown Tech. College 
P.O. Box 1966 
Conway, SC 29526 

COMMUNICATION COORD. (CORE) 

David Wyse 

Professional Business Software 
3680 Wyse Road 
Dayton, OH 45414 
(513) 890-1800 x223 
LIBRARIAN 

Joseph L. Bingham 
Mantech International 
2320 Mill Road 
Alexandria. VA 22314 
LUG COORDINATOR (CORE) 

Dave Schmidt 

Management Sciences Associates 
5100 Centre Avenue 
Pittsburgh. PA 15232 
STORE REPRESENTATIVE 
G. Beau Williamson 
Rockwell International 
1200 N. Alma Road 
MIS 406-280 
Richardson. TX 75081 
(214 ) 996-5547 
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SUBMITTING ARTICLES TO HARD NEWS 


The purpose of HARD NEWS, the HMS SIG newsletter, is to 
serve as a forum to share information related to DEC 
hardware with the members of the SIG. As such, the 
existence of the newsletter is entirely dependent on your 
contributions. If you have an HHK item, a better or safer 
way to do something, product news, a tutorial article of 
general interest, etc., we would like to publish it in the 
newsletter. We hope that HARD NEWS will be published at 
least six times a year. 

You can submit material to the editor, Carmen Wiseman, or to 
the HMS SIG chair. Bill Walker. We can accept submissions 
in a wide variety of formats: 

o Items can be sent to the editor on VMS-format RX50s, 
TK50 cartridges, or IBM PC format 5 1/4" floppies. The 
SIG chair prefers RT-11 floppies but can handle any 
reasonable media. 

o Hard copy, like cash, is always acceptable. 
Camera-ready copy will save us a lot of typing, but we 
don't insist on it. You can also use the Hardware 
Submission Form in the "Questionnaires" section of the 
combined SIGs Newsletters. 

o Those of you with access to DCS can send things to 
WALKER or WISEMAN. DCS is usually checked on a daily 
basis. 

o You can reach the SIG chair on CompuServe as 
"Bill Walker 71066,24" or via EasyLink mailbox 62752448 
or MCI Mail account 333-1675. You can reach the editor 
via EasyLink mailbox 62960090 (be sure to say ATTN: or 
TO: Carmen Wiseman somewhere in the body of the 

message). 

If you have anything to submit, send it1 If it is a mess. 
But we can read it, we will get it into the newsletter 
somehow. Finally, if you have any questions about 
submitting material, call one of us. The telephone numbers 
are listed below. 


Contributions can be sent to: 

William K. Walker 
Monsanto Research Corp. OR 
P.O. Box 32 A-152 

Miamisburg, OH 45342 
(513) 865-3557 (work) 

(513) 426-7094/0344 (home) 


Carmen D. Wiseman 

Digital Review 

Prudential Tower, Suite 1390 

800 Boylston Street 

Boston, MA 02199 

(617) 375-4361 (work) 


SUB-1 
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Ask the WOMBAT WIZARD 
Submission Form 


To sqbmit a problem to the WIZARD, please fill out the form below 
and send it to: 


WW Editor, Philip A. Naecker 
Consulting Software Engineer 
3011 North Mount Curve Avenue 
Altadena, CA 91001 
USA 


Name:_ DECUS Membership No. 

Affiliation:_ 

Address: 


Telephone Number:_ 

Statement of Problem: 


Please following the following guidelines when submitting support 
material: 

1. If you are trying to demonstrate a method or a concept, 
please simplify the procedures, records, and other information 
to the shortest form possible. 

2. Annotate your attachments. Simple comments or hand-written 
notes ("Everything worked until I added this statement.") go a 
long way toward identifying the problem. 

3. Keep an exact copy of what you send. And number the pages 
on both copies. But send everything that is related to your 
question, even remotely. 

4. If you would like a direct response or would like your 
•materials returned, please don't forget to include a stamped, 
self-addressed envelope large enough to hold the materials you 
send. 



QU-l 



DATATRIEVE/4GL SIG 

Product Improvement Request Submission Form 


Submitter: 
Address: 


DECUS Membership Number: 
Firm: 


Phone: 


Product or Products: 


How to write a PIR 

A PIR should be directed at a specific product or group of 
products. Be sure to give the full name of the product(s) and 
version numbers if applicable. Describe the functionality you 
would like to see in as complete terms as possible. Don't assume 
that the PIR editors or software developers know how it is done 
in some other software product - state specifically how you want 
the software to function. Provide justification of your request 
and give an example of its use. If you can, suggest a possible 
implementation of your request. 


Abstract: (Please limit to one or two short sentences.) 


Description and Examples: 


(Use additional pages as necessary.) 


(Put my name and address on reverse side, thus:) 


PIR Editor, Philip A. Naecker 
Consulting Software Engineer 
3011 North Mount Curve Avenue 
Altadena, CA 91001 
USA 


QU-3 
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HARDWARE SUBMISSION FORM — A SIG INFORMATION INTERCHANGE 
Message 


Contact 

Name 

Address 


Telephone 


Type of equipment 


SUBMIT ANY TYPE OF HARDWARE PROBLEMS AND/OR FIXES. 


SEND TO: 

William K. Walker 
Monsanto Research Corp. OR 
P.O. Box 32 A-152 

Miamisburg, OH 45342 


Carmen D. Wiseman 
Digital Review 

Prudential Tower, Suite 1390 
800 Boylston Street 
Boston, MA 02199 


QU-5 



Languages Sc Tools SIG — Masters Directory 


16 


MASTERS APPLICATION 

Name:_Title_ 

Company:_ 

Address:_ 


Network Address: 


Phone: ( ) _ 

_Date: 


The Languages & Tools SIG has established the designation “LANGUAGES AND TOOLS MASTER*, to be applied 
to selected, qualified people willing to share their expertise in various subjects with others. Masters are people who are 
knowledgeable enough in one or more languages or tools to be comfortable answering questions about them. The 
qualifications of an L&T Master are: expertise in a specific area, a willingness to have his/her name published as a Master, 
and a willingness to volunteer services in different ways. Each product may have several Masters, and there is an overall 
Masters Coordinator who is a member of the L&T Steering Committee. 

Masters are asked to serve other users (and, under some circumstances, DEC), as a resource on products within their 
competence. In addition to being listed in the L&T Masters Directory (published in the newsletter) as available for 
occasional telephone consultation, Masters may act as ‘Doctors’ at Symposium Clinics, present Symposium sessions on the 
products of interest to them, field test products, interact with DEC product managers when appropriate, or act as a 
reference for a product for Digital salespeople. Especially on mature products, the SIG is anxious for knowledgeable users 
to offer product tutorial sessions at Symposia, and Masters can be of great help here. At Symposia, Masters will wear an 
identifying button bearing the legend “Ask Me About.* and the name of the language or tool in which he/she specialises. 

If you’d like to serve as an L&T Master, please mark the products on which you are willing to answer questions with 
an (for Master). Please mark any other products running at your site with an U A” (for “also running”) to provide 

users with a broader picture of your facilities. (Although not an L&T product, Mumps is included here at the request of 
the Mumps SIG as a service to Mumps users). You may request removal of your name from the Masters Directory at any 
time, although you may continue to be listed for a month or two, because of publication lead times. 

I am qualified to act as an L&T Master for the following products: Q] Mumps 



Debug 


Bliss 


CMS 


TPU 


C 



Pascal 


Basic 


MMS 


EVE 


Ada 1 



Fortran 


Cobol 


LSE 


EDT 


APL 



Document 


Dibol 


SCA 


TECO 


RPG 



VAX Notes 


Emacs 


PCA 


PL/I 


Scan 



Test Manager 
Runoff & DSR 
TfcX & UT e X 
Cobol Generator 
Software Project Mgr 


Briefly describe your experience with those you checked. 


How long have you held your present position?---- 

Are you able to attend at least one symposium each year?--- 

Users are encouraged to seek assistance with products by calling appropriate Masters listed in the Directory. As a 
Master, your name and telephone number will be published in the Masters Directory, and users will call on you for limited 
help from time to time. Please check, below, any additional activities you might do: 

| | Field-test new versions of your product at your work site. 

1 | Provide feedback on the product when needed by its DEC product manager. 

| | Act as a reference for the product at the request of Digital Sales or Marketing people. 

Mail to: Dena Shelton, L&T SIG Masters Coordinator, Cullinet Software, Inc., 2660 Z&nker Road, 
Suite 206, San Jose, CA 95134. 

7 7 nf t m 


*Ada is a trademark of the DoD 









Languages & Tools SIG 
WISHLIST QUESTIONNAIRE 

Name:_Title_ 

Company:__ 

Address:___ 


-Phone: ( ) __ 

Network Address:_Date:_ 

The Languages k Tools SIG is principally concerned with the DEC and public domain software products listed 
below. If your request directly involves one of these products, please check which one (if you have more than one 
request, please use a separate form for each): 



Debug 


Bliss 


CMS 


TPU 


C 



Pascal 


Basic 


MMS 


EVE 


Ada 1 



Fortran 


Cobol 


LSE 


EDT 


APL 



Document 


Dibol 


SCA 


TECO 


RPG 



VAX Notes 


Emacs 

i 

PCA 


PL/I 


Scan 



Test Manager 
Runoff k DSR 
TfcX k IAT e X 
Cobol Generator 
Software Project Mgr 


If your request or suggestion doesn’t relate to one of the products listed above, check which one of the following 
Language k Tools SIG topics it concerns: 


— 

Newsletter 

Masters Program 


Symposium Sessions 

Working Group Activities 

— 

Pre-Symposium Seminars 
Session Notes 

— 

Information Folder 

Other L&T SIG topic: 

□ 

SIG Tape 

— 

DECUS Store Item 


Wish List Request —brief description: 


Complete description—please explain your request thoroughly; don’t assume we know details of other products or 
services; give examples._ 


Mail to: Shava Nerad, L&T Wishlist Coordinator, MIT, 77 Mass Ave. W91-219A, Cambridge, MA 
02159; (617)255-7458 


*Ada It a trademark of the DoD 
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DATAGRAMS are short messages, comments, requests, or answers 
that are published in NETwords. Please fill in the sections below 
and send the DATAGRAM to: 

JUDI MANDL 

UCONN HEALTH CENTER 

263 FARMINGTON AVENUE, BLDG. #19 

FARMINGTON, CT 06032 


Title:_ 

Message: 


Your Name: _ 

Address: _ 

Telephone: _ 

If this is a reply to a previous DATAGRAM, what *7 _ 

Signature:_Date:_ 


QU-ll 





Place | 
Stamp | 
Here j 


JUDI MANDL 

UCONN HEALTH CENTER 

263 FARMINGTON AVENUE, BLDG. #19 

FARMINGTON, CT 06032 


Iol<3 Here 
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Name (optional) 
Address (optional) 


RT-11 WISH LIST SURVEY 


DECUS Number (optional) 


1.1 

3.1 

3.7u 

3.13a 

5.1b 

1.2 

3.2a 

3.7v _ 

3.13b 

5.2a 

1.3 

3.2b 

3.7w 

3.13c 

5.2b 

1.4 

3.2c 

3.7x 

3.13d 

6.1 

1.5 

3.2d 

_ 3.7y _ 

3.14 

6.2a 

1.6 

3.2e 

3.7z _ 

3.15 

6.2b 

1.7a 

3.3a 

3.7aa 

3.16 

6.2c 

1.7b 

3.3b 

3.7bb _ 

3.17a 

6.2d 

1.8 

3.3c 

3.7cc 

3.17b 

6.3 

1.9a 

3.3d _ 

“ 3.7dd _ 

3.17c 

6.4a 

1.9b 

3.4a 

3. 7ee 

3.17d 

6.4b 

1.9c 

3.4b _ 

3.8a 

3.17e 

6.4c 

1.9d 

3.4c 

^ 3.8b _ 

3.17f 

6.4d 

1.10 

3.5a 

3.8c 

3.18 

6.5 

1.11 

3.5b _ 

3.9a 

3.19a 

6.6a 

1.12 

3.6a 

3.9b 

3.19b 

6.6b 

1.13 

3.6b _ 

3.9c 

3.19c 

6.6c 

1.14 

3.6c 

3.9d 

4.1 

6.6d 

2.1 

3.6d _ 

3.9e 

4.2a 

6.7 

2.2 

3.6e 

3.9f 

4.2b 

6.8a 

2.3 

3.6f 

3.9g 

4.3 

6.8b 

2.4 

3.6g 

3.9h 

4.4a 

6.8c 

2.5 

3.7a 

3.9i 

4.4b 

6.8d 

2.6 

3.7b 

3.9 j 

4.5a 

6.8e 

2.7 

3.7c 

3.9k 

4.5b 

7. 

2.8 

3.7d 

3.10a 

4.6 

8. 

2.9 

3.7e 

3.10b 

4.7a 

9.1 

2.10 

3.7f 

3.10c 

4.7b 

9.2a 

2.11 

_ 3- 7 g _ 

3. lOd 

4.7c 

9.2b 

2.12 

3.7h 

3. lOe 

4.7d 

9.3a 

2.13 

3.7i 

3. lOf 

4.7e 

9.3b 

2.14 

_ 3.7 j _ 

3. lOg 

4.7f 

10.1 

2.15 

3.7k 

3. lOh 

4.7g 

10.2 

2.16 

3.71 

3. lOi 

4.7h 

10.3 

2.17 

3.7m 

3.10 j 

4.7 i 


2.18 

3.7n 

3.10k 

4 • 7 j 


2.19 

3.7o 

3.101 _ 

4.7k 


2.20 

3.7p 

3.10m 

4.71 


2.21 

3.7q 

3. lOn 

4.7m 


2.22 

3.7r 

3.11a 

4.7n 


2.23 

3.7s 

3.11b 

4.7o 


2.24 

3.7t 

3.12 

5.1a 



Send Responses to: RT-11 Wish List Survey 
Multiware, Inc. 

2121-B Second St. Suite 107 
Davis, CA 95616 q U13 





DECUS 


DECUS U.S. CHAPTER 

SUBSCRIPTION SERVICE SIGS NEWSLETTERS ORDER FORM 

(U.S. Members Only) 


As a member of DECUS U.S. Chapter, you are entitled to contribute and subscribe to the DECUS monthly publication, SIGs 
Newsletters. You also have the opportunity to subscribe to the Symposia Proceedings which are a compilation of the reports 
from various speakers at the U.S. National DECUS Symposia. 


• No Purchase Orders will be accepted. 

• The order form below must be used as an 
invoice. 

• All checks must be made payable to DECUS. 

• All orders MUST be paid in full. 

• Minimum of $25.00 for orders placed via a 
credit card. 


• No refunds will be made. 

• The address provided below will be used for all DECUS 
mailings; i.e. Membership, Subscription Service and Symposia. 

• SIGs Newsletters Price is for a one-year subscription beginning 
the month following receipt of payment. 


Name_____DECUS Member # 

Company___ 

Address___ 


City_______State_ _ Zip _ 

Telephone # ( _)_________ 


Subscription Service Offering 

Unit Price 

Quantity 

Total 

SIGs Newsletters 

$35.00 



Spring '87 Proceedings (SP7) 

15.00 

— 

.. .. .. 

Fall ’87 Proceedings (FA7) 

15.00 


_ 

Spring ’88 Proceedings (SP8) 

15.00 

. ... 

_ _- 

Fall ’88 Proceedings (FA8) 

15.00 

_ 



Total Amount $_ 

□ MASTERCARD □ VISA □ DINERS CLUB/CARTE BLANCHE® □ AMERICAN EXPRESS 
Credit Card #_____Expiration Date 

I understand that there will be no refunds even if I decide to cancel my subscription. 

Signature_____ ___________ 
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DECUS U.S. CHAPTER 
APPLICATION FOR MEMBERSHIP 


□ New Membership □ Update to current membership profile Current DECUS Member #_ 

Please provide a complete mailing address, include zip code in accordance with postal regulations for your locality. 

Are you an employee of Digital Equipment Corporation? □ YES □ NO 


NOTE: Please print clearly or type! 

Name_ 

(First) (Middle Initial) (Last/Family Name) 

Company; _ 

Address;_ 


City/Town/State/Zip: 


Telephone: Home( 


Work ( ) 


How Did You Learn About DECUS? Please Check Applicable Item. 


1 □ 

ANOTHER DECUS MEMBER 

4 D DIGITAL SALES 

13 □ 

LOCAL USERS GROUP 

2 D 

SYMPOSIA 

5D HARDWARE PACKAGE 

14 □ 

SPECIAL INTEREST GROUP 

eD 

DECUS CHAPTER OFFICE 

6 O SOFTWARE PACKAGE 

7 □ 

SOFTWARE DISPATCH (Digital Newsletter) 

ioD 

DIGITAL STORE 

12 □ ADVERTISING 




Do you wish to be included in mailings conducted by Digital (for marketing purposes etc?) □ Permission 

□ Refusal 


Type Of Digital Hardware Used: Please Check Those Applicable To You 


20 □ 

DECMATE 


52 □ LSI-11 


21 □ 

PROFESSIONAL 5 □ 

WPS-8 


82 □ 

DECSYSTEM-10 

3 G PDP-8 FAMILY 

22 □ 

RAINBOW 

51 □ 

WPS-11 


83 □ 

DECSYSTEM-20 

50 □ PDP-11 

FAMILY 

54 □ 

VAX FAMILY 




Major Operating System*? Languages Used: Please Check Those Applicable To You 



1 □ 

ADA 

26 □ 

CORAL-66 

47 □ 

FOCAL 

67 □ 

OS/8 

109D 

RT-11 

2 G 

ALGOL 

28 □ 

COS 

48 □ 

FORTRAN 

68 □ 

PASCAL 

97 □ 

TECO 

5 D 

APL 

34 □ 

DATATRIEVE 

51 □ 

GAMMA 

72 □ 

PL-11 

70 □ 

TOPS-10 

?□ 

BASIC 

35 □ 

DBMS 

110D 

IAS 

92 □ 

RPG 

71 □ 

TOPS-20 

17 □ 

BLISS 

38 □ 

DECNET 

53 □ 

IQL 

81 □ 

RSTS/E 

111 □ 

ULTRIX/UNIX 

19 □ 

C 

43 □ 

DIBOL 

58 □ 

MACRO 

83 □ 

RSX 

104D 

VMS 

22 □ 

COBOL 

45 □ 

DOS-11 

65 □ 

MUMPS 

91 □ 

RMS 

107D 

WPS-8 
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Type Of Business (Environment)/Computer Applications 

Please Check That Which Best Describes Your Business Application 


21 □ 

ACCOUNTANCY 

i □ 

EDUCATION/PRIMARY 

23 0 

NUMERICAL CONTROL 

7 □ 

BANK 

20 

EDUCATION/SECONDARY 

68 0 

OEM-COMMERCIAL 

64 □ 

BUSINESS/COMMERCIAL 

61 □ 

EDUCATION-TECHNOLOGY 

78 0 

OEM-TECHNICAL 

74 □ 

BUSINESS/INFORMATION SYSTEMS 

30 

EDUCATION/UNIVERSITY 

56 0 

PHYSICAL SCIENCES 

57 □ 

CHEMISTRY 

67 0 

ENGINEERING 

20 □ 

RESEARCH/DEVELOPMENT 

54 □ 

CLINICAL LABORATORY 

65 0 

FINANCE/ACCOUNTING 

10O 

RETAIL 

63 □ 

COMPUTATION 

77 0 

GOVERNMENT 

73 0 

SOFTWARE DEVELOPMENT 

11 □ 

CONSUMER ELECTRONICS 

75 0 

GRAPHICS 

53 0 

TELECOMMUNICATIONS 

18 D 

CONSULTANT 

40 

HOSPITAL 

190 

TELEPHONE/UTILITIES 

72 □ 

DATA ACQUISITION 

62 0 

INDUSTRIAL 

51 □ 

TIMESHARING 

52 □ 

DATA COMMUNICATIONS 

55 0 

LABORATORY/SCIENTIFIC 

80 □ 

TRAINING/INSTRUCTION 

130 

DATA PROCESSING SERVICES 

140 

LIBRARY 

66 0 

TYPESETTING/PUBLICATION 

71 □ 

DATA REDUCTION 

58 0 

LIFE SCIENCES 



170 

DIGITAL EMPLOYEE-ENGINEERING 

70 □ 

MANUFACTURING 



150 

DIGITAL EMPLOYEE-MARKETING 

79 0 

MARKETING 



160 

DIGITAL EMPLOYEE-SERVICE GROUP 

59 0 

MEDICAL RESEARCH 



60 □ 

EDUCATIONAL ADMINISTRATION 

60 

MILITARY INSTALLATION 




Special Interest Groups(SIGs) Enrollment 

I Wish To Participate In The Following DECUS U. S Chapter Special Interest Groups. 


3 G ARTIFICIAL INTELLIGENCE 

7 □ BUSINESS APPLICATIONS 
2 □ COMMERCIAL LANGUAGES 
6 □ DATA MGMT. SYSTEMS 

31 □ DAARC (LABS) 

5 G DATATRIEVE/4GL 

8 □ EDUSIG 

10 □ GRAPHICS APPLICATIONS 


11 □ HARDWARE AND MICRO 
35 □ IAS 

27 □ LARGE SYSTEMS 
16 □ L&T 

14 □ MUMPS 

15 □ NETWORKS 

34 □ OFFICE AUTOMATION 


36 □ PERSONAL COMPUTER 

18 □ RSTS'E 
17 □ RSX 

19 □ RT-11 

32 □ SITE MGMT. & TRNG 
21 □ UNISIG 
26 □ VAX 


Job Title/Position- Please Check: 

1 □ CORPORATE STAFF 

2 □ DIVISION OR DEPARTMENT STAFF 
30 SYSTEMS ANALYSIS 

4 □ APPLICATIONS PROGRAMMING 

5 D SYSTEMS ANALYSIS/PROGRAMMING 

6 □ OPERATING SYSTEM PROGRAMMING 

7 □ DATABASE ADMINISTRATION 

8 □ DATA COMMUNICATIONS/TELECOMMUNICATIONS 
90 COMPUTER OPERATIONS 

10 □ PRODUCTION CONTROL 


101 □ CORPORATE DIRECTOR OF DP/MIS 
1020 ADMINISTRATIVE ASSISTANT 
1030 TECHNICAL ASSISTANT 

104 □ SERVICES COORDINATOR 

105 □ MANAGER 
1060 ANALYST 

107 0 PROGRAMMER 
108D DATABASE MANAGER 
109 □ DATABASE ADMINISTRATOR 
110O MANAGER OF DP OPERATIONS 


Citizen of The United States of America? □ YES □ NO Country;_ 

Signature___ Date. 

Forward To: DECUS U. S Chapter 

Digital Equipment Computer Users Society 

Membership Processing Group 

219 Boston Post Road, BP02 

Marlboro MA 01752-1850 

Phone (617)480-3418 

DTN: 8-296-3418 
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Printed in the U.S.A. 


“The Following are Trademarks of Digital Equipment Corporation” 


DATATRIEVE 

PDP-11 

RT-11 

DDCMP 

P/OS 

RX02 (et. al) 

DEC 

Q-bus 

UDA50 

DECmate 

RALLY 

UNIBUS 

DECnet 

Rdb 

VAXsim 

DECUS 

ReGIS 

VAXstation 

IAS (et. al) 

RMS-11 

VAX/VMS 

LN03 

RSTS/E 

VMS 

MicroVAX 

RSX 

VT-50 (et. al) 

Micro VAX 1 (et. al) 

RSX-11M- PLUS 

WPS 

Micro VMS 

RT 

WPS-PLUS 
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All Rights Reserved 

The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equip¬ 
ment Corporation or DECUS. Digital Equipment Corporation and DECUS assume no responsibility for any errors that may appear 
in this document. 

It is assumed that all articles submitted to the editor of this newsletter are with the authors’ permission to publish in any DECUS 
publication. The articles are the responsibility of the authors and, therefore, DECUS Digital Equipment Corporation, and the editor 
assume no responsibility of liability for articles or information appearing in the document. The views herein expressed are those of 
the authors and do not necessarily express the views of DECUS or Digital Equipment Corporation. 

AMP is a tademark of AMP Special Industries, Inc.; AT&T is a trademark of American Telephone & Telegraph Co.; CP/M is a 
registered trademark of Digital Research, Inc.; FCS is a registered trademark of THORN EMI Computer Software; HP is a 
registered trademark of Hewlett-Packard Company; IBM is a registered trademark of International Business Machines Corporation; 
MS-DOS is a trademark of Microsoft Corporation; RMS is a trademark of American Management Systems, Inc.; TSX-PLUS is a 
trademark of S&H Computer Systems, Inc.; UNIX is a registered trademark of American Telephone & Telegraph Company ;VS is a 
trademark of Wang Laboratories, Inc.; Xerox is a registered trademark of Xerox Corporation. 


Production Staff: 

Beverly Welborne: Communications Committee Chair 
R.E. Center 

Frank Borger: SIG Publications Chair 
Michael Reese Hospital 

Judy Mulvey: Publications Manager 
DECUS 

Judy Tessien Phototypographer/Graphics Designer 
DECUS 


Circulation: 6165 



STATUS CHANGE 

Please notify us immediately to guarantee 
continuing receipt of DECUS literature. Allow 
up to six weeks for change to take effect. 

( ) Change of Address 

( ) Please Delete My Membership Record 

(I Do Not Wish To Remain A Member) 

DECUS Membership No:__ 

Name:_ 

Company:_ 
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State/Country:_ 
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Mail fa DECUS - Attn: Subscription Service 
219 Boston Post Road, BP02 
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